Subject: RE: Spnego and interoperability--Running code

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 1 Dec 2004 13:12:28 -0800

Here is the proposed text to be appended to appendix B.

--------------------------------------------------------------------
   An implementation that conforms to this specification  will not
   interoperate with a strict 2748 implementation.  Even if the new
   implementation always sends a mechlistMIC token, it will still fail
   to interoperate.  If it is a server, it will fail because it requests
   a mechlistMIC token using an option that older implementations simply
   do not support.  Clients will tend to fail as well.

   As an alternative to the approach chosen in this specification, we
   could have documented a correct behavior that is fully backward
   compatible with RFC 2478 and included an appendix on how to
   interoperate with existing incorrect implementations of RFC 2478.

   As a practical matter, the SPNEGO implementers within the IETF have
   valued interoperability with the Microsoft implementations.  We were
   unable to choose to maintain reasonable security guarantees, maintain
   interoperability with the Microsoft implementations and maintain
   interoperability with correct implementations of RFC 2478.  The
   working group was not aware of any RFC 2478 implementations.  Even if
   there are RFC 2478 implementations, it is unlikely that they will
   interoperate because of a critical flaw in the description of the
   encoding of the mechanism list in RFC 2478.

   With the approach taken in this specification, we get security
   between new implementations all the time while maintaining
   interoperability with the implementations we have within the IETF
   community.  The working group believes that this justifies breaking
   compatibility with a correct implementation of RFC 2478. 

-----------------------------------------------------------------

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Tuesday, November 30, 2004 9:50 PM
To: [email-masked]
Subject: Re: Spnego and interoperability--Running code

Speaking as chair, I believe that this is a rationale argument in favor
of the changes made to RFC 2478.  I believe that this argument should be
summarized and included in "Appendix B" of the document.  I would
appreciate it if someone could post such text for consideration.

Jeffrey Altman

Sam Hartman wrote:

> Especially in working groups where I'm fairly active as an individual 
> contributor, I'l try and explicitly lable when I'm speaking as area 
> director.  I'll also generally label when I'm speaking as an 
> individual, but if there is doubt I'm probably speaking as an 
> individual.  This message is definitely my individual opinion.  I'm 
> hoping to try and explain why the interoperability approach we're 
> adopting in the new SPNEGO protocol is correct.
> 
> Martin brought up a good point in the SPNEGO discussion.  Roughly as I

> understand it, he is concerned that we're catering to the Microsoft 
> implementation rather than what RFC 2478 says.
> 
> An implementation that conforms to Larry's draft will not interoperate

> with a strict 2748 implementation.  Even if the new implementation 
> always sends a MIC, it will still fail to interop.  If it is a server,

> it will fail because it requests a MIC using an option that older 
> implementations simply do not support.  I believe clients will tend to

> fail too.
> 
> This is not ideal.  I'm going to try and justify why I believe this is

> the right course of action for the IETF.
> 
> The IETf is about producing a working Internet--running code is at the

> core of our mission statement.  We write specs for two reasons.
> First, without having a written document to discuss, we find it hard 
> to judge rough consensus.  Second, we have found that clear 
> specifications are the best way to get running code.
> 
> As a practical matter, the SPNEGO implementers within the IETF have 
> valued interoperability with the Microsoft implementation.
> 
> SPNEGO is at proposed standard; it is reasonable for us to modify or 
> withdraw the specification based on implementation experience.  It's 
> unfortunate that it has been sitting at proposed standard so long, but

> that's where we are.  martin made an argument that the base GSS-API 
> and C bindings spec are actually more mature than their standars level

> indicates.  I agree with that argument but do not think it applies for

> SPNEGO.  For one thing, the spec is critically flawed in that it 
> doesn't tell you what encoding to use.  Tom indicated that there are 
> at least three possible encodings; discussion on the list suggested 
> that the choice of encoding is rather arbitrary.  Even if there are 
> RFC 2478 implementations out there, they may end up not interoperating

> with themselves because of this defect in the spec.
> 
> Martin proposed that we document correct behavior and include an 
> appendix on how to interoperate with existing incorrect 
> implementations.  In principle that seems like a fine idea.  However 
> without changing what correct behavior is somewhat, there is no way to

> be secure and to interoperate with existing implementations.  If we 
> are willing to adopt Larry's approach, we get security between new 
> implementations all the time while maintaining interoperability with 
> the implementations we have within the IETF community.
> 
> In my mind this is the best of the available bad solutions.
> 
> --Sam
> 
> 
> _______________________________________________
> 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: Jeffrey Altman <[email-masked]>
Date: Wed, 01 Dec 2004 17:06:57 -0500

> Here is the proposed text to be appended to appendix B.

Thank you.  This is what I am looking for.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Dec 2004 16:59:37 -0600

> Here is the proposed text to be appended to appendix B.

The only change I would recommend is to add a clause to the first
sentence of the last paragraph: "With the approach taken ... all the
time while maintaining interoperability with some implementations ... in
common, but not all, cases."

I support this text.

Nico
--