Subject: Re: Spnego and interoperability--Running code

From: Jeffrey Altman <[email-masked]>
Date: Wed, 01 Dec 2004 00:50:20 -0500

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 Hutzelman <[email-masked]>
Date: Wed, 01 Dec 2004 15:40:55 -0500

> implementation rather than what RFC 2478 says.

This is really very similar to what we just did with Kerberos:

- There is an existing specification which is vague and underspecified.

- There is a widely-deployed reference implementation which disagrees
  with the existing specification in several ways.

- The reference implemenation was developed prior to or in parallel with
  the existing specification.

- It is impossible to both comply with the existing specification and
  interoperate with the reference implementation.

- There are multiple existing implementations which do interoperate with
  the reference implementation and with each other.

In the case of Kerberos, it turns out to be difficult-to-impossible to 
interoperate with both the reference implementation and a strictly 
conformant one.  In this situation, we chose to update and correct the 
specification to reflect the behavior of the reference implementation and 
others that interoperate with it, even though we knew of the existence of 
strictly-RFC1510-conformant implementations (deployed mostly on private 
networks).

Interoperability with existing implementations won out over 100% 
compatibility with a broken specification which was not widely deployed on 
the public Internet.

This was the correct course of action for Kerberos, and I believe it is the 
correct course of action for SPNEGO.

-- Jeff