Subject: RE: Open Issues on draft-ietf-kitten-2478bis

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Tue, 23 Nov 2004 23:00:05 -0800

Jeff wrote:
>    Is there consensus on the mailing list?

Humm... This sounds a call for the duty of the chair. 

Folks, if you spoke before, I urge you to speak again.

Ken, Sam, Nico, Wyllys, and me preferred "SHOULD", please speak if this
is accurate. 

Love, Luke, please comment, thanks.

> Does anyone have some
> proposed text for this or should it be dropped?

negative. Nico and Sam, you were on the last thread on this subject.

> There was a discussion on the history of the term "mechanism
>   variants".  

Section 6 actually described what is a "mechanism variant". I agree we
can add a forward reference here.

5) and &) seem to be related, if not the same.

> proposed changes to published documents be sent to the mailing list 

I just want to raise an observation that changes in isolation are rather
hard to comprehend in general. 

But in this case this makes sense as we are fairly close to last calling
the document.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Tuesday, November 23, 2004 9:20 PM
To: [email-masked]
Subject: Open Issues on draft-ietf-kitten-2478bis

Folks, I am back from vacation.  There are some open issues which I need
to have a resolution to based upon the discussion at IETF61 and the
e-mail communication on this list over the last ten days.

(1) At IETF61 there was a consensus call in the meeting room asking
     whether it was more important to maintain backward compatibility
     then to add new features to the protocol.  There was unanimous
     consensus in the room that backward compatibility was more
     important.

(2) At IETF61 there was a consensus call in the meeting room asking
     whether or not the use of mechanisms which do not support integrity
     protection should be prohibited in 2478bis.  There was a very
     strong feeling in the room that these mechanisms should be
     prohibited.  Is this the consensus of the participants of
     this mailing list?

     My concerns about adding this prohibition are that it may break
     backward compatibility for some implementations of 2478 which
     we are not aware of.  As such I believe doing so would be in
     conflict with (1).

(3) At IETF61 there was a consensus call in the meeting room asking
     whether the use of optimistic tokens will be specified in 2478bis
     as a "SHOULD" or a "MAY".  There was no consensus in the room.
     Is there consensus on the mailing list?

(4) Martin raised the possibility that implementations of SPNEGO outside
     of the current list participants might be broken by the new SOMIC
     rules or other changes.  In the absence of additional data it is
     very hard to make a determination as to how great a risk this is.
     What I am wondering is what we can do to try and track down some
     of these additional implementations?  Martin, do you have any
     ideas?

(5) There was discussion on the list on the subject of whether or
     not there should be explicit text added to the draft recommending
     that implementations replace a SPNEGO token with a mech specific
     token when only one mech is available in the initiator.  It seems
     to me that doing so would improve the security of the protocol
     as well as improve the performance.  I did not see the discussion
     reach a conclusion one way or the other.  Does anyone have some
     proposed text for this or should it be dropped?

(6) There was a discussion on the history of the term "mechanism
     variants".  I would prefer to either see undefined terms be removed
     from documents or be defined.  Martin, could you propose some text
     to be added to the document which can be used to define the meaning
     of this term?

(7) There was discussion on the list of the "multi-layer negotiation is
     considered harmful argument" and whether or not text should be
added
     to this document on the subject.   Does anyone have some proposed
     text for this or should it be dropped?

I realize that the holidays are fast approaching.  It is my hope to be
able to get this document to the IESG before the end of the year.  To
meet that goal I must ask that folks who have been putting off reviewing
the document until it becomes stable do so now.

The process I would like to follow in this group is that proposed
changes to published documents be sent to the mailing list and only be
incorporated into the documents by the editor after consensus on the
proposed text has been reached on the list.  I believe this process will
allow us to move documents ahead at a faster pace with more consistent
review.

Thanks.

Jeffrey Altman

P.S. - Happy Thanksgiving to all.

_______________________________________________
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: Luke Howard <[email-masked]>
Date: Thu, 25 Nov 2004 10:03:23 +1100

>> We would prefer SHOULD. Indeed, Heimdal right now requires the
>> optimistic token (and this is unlikely to be fixed until it gets
>> mechglue).
>
>I'm a little surprized?  Do you mean that your SPNEGO acceptor will
>break if it receives an initial SPNEGO token without an optimistic
>context token?

Yes. I agree it's wrong, and it needs to be fixed, but it's a little
difficult due to the way SPNEGO is implemented in Heimdal. Fixing it
is on my todo list (see related discussion on heimdal-discuss).

-- Luke

--

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 24 Nov 2004 15:37:35 -0800

Martin Rex wrote:

> I do not think it improves security either.

We already established that if this creates a security weakness, because
it prevents the SPENGO server from demanding mechlistMIC when that is
needed.

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Wednesday, November 24, 2004 3:23 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: Open Issues on draft-ietf-kitten-2478bis

Sam Hartman wrote:
> 
>     Jeffrey> (5) There was discussion on the list on the subject of
>     Jeffrey> whether or not there should be explicit text added to the
>     Jeffrey> draft recommending that implementations replace a SPNEGO
>     Jeffrey> token with a mech specific token when only one mech is
>     Jeffrey> available in the initiator.  It seems to me that doing so
>     Jeffrey> would improve the security of the protocol as well as
>     Jeffrey> improve the performance.  I did not see the discussion
>     Jeffrey> reach a conclusion one way or the other.  Does anyone
>     Jeffrey> have some proposed text for this or should it be dropped?
> 
> I think it should be dropped.  I don't see how it improves security.

I do not think it improves security either.

That was only to improve interoperability with gssapi mechanisms that
don't have an accompanying SPNEGO.

-Martin

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 24 Nov 2004 17:03:23 -0800

Martin Rex wrote:
 > Now if implementors get that part of rfc2478 wrong, then I don't have
any hope that implementors get the current 
> rfc2478bis right, because it is a least a magnitude more complex.

I strongly disagree, vanilla 2478 is impossible to implement because it
is underspecified. I have at least 3 implementers who indicated to me
independently 2478bis is very easy to translate into code!

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Wednesday, November 24, 2004 2:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Open Issues on draft-ietf-kitten-2478bis

That this token was optional was quite obvious from the rfc2478 spec,
and that spec is so short that it is hard to misread or misinterpret
this part.

Now if implementors get that part of rfc2478 wrong, then I don't have
any hope that implementors get the current rfc2478bis right, because it
is a least a magnitude more complex.

-Martin

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 24 Nov 2004 17:05:51 -0800

Martin Rex wrote:
> then I have Ken on the record for MAY (from his posting to this
mailing list, I don't know about IETF hallway 
> discussions).

Ken is for "SHOULD". See attached.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, November 24, 2004 2:50 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: Open Issues on draft-ietf-kitten-2478bis

Liqiang\ wrote:
> Ken, Sam, Nico, Wyllys, and me preferred "SHOULD", please speak if 
> this is accurate.

If the consensus context was about the MAY or SHOULD support optimistic
token, then I have Ken on the record for MAY (from his posting to this
mailing list, I don't know about IETF hallway discussions).

Folks, this is NOT about whether we put MAY or SHOULD into an entirely
new document.  This is about whether there are strong reasons that
justify changing a MAY into a SHOULD for an existing spec.

As it is, such a change will not affect interoperability, so a change is
neither necessary nor advisable.

> can add a forward reference here.

Sorry, but I strongly disagree.
Section 6 further adds to the confusion by being extremely
ambiguous/vague, and the motivation for rev'ving rfc2478 was to reduce
ambiguity.

Either we drop the mentioning of variants entirely or we standardize
them in a non-ambiguous fashion. (Which might prove rather difficult,
given the original ambiguity an few, if any, actual use in
implementations.

Anyone from Bull or the Original SESAME project listening?

SESAME was the European counterpart for DCE, partly funded as a research
project of the Europeaon union and a cooperation of at least one
University and three companies Bull (FR), SSE/Siemens (IR) and ICL (UK)
?

-Martin

Subject: Re: Comments on Larry's SPNEGO draft
From: "Ken Raeburn" <[email-masked]>
To: "Liqiang\(Larry\) Zhu" <[email-masked]>, <[email-masked]>
Date: Fri, 5 Nov 2004 17:21:46 -0800

*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