Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt

Martin Rex <Martin.Rex@sap.com> Thu, 19 April 2007 15:54 UTC

Return-path: <spkm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYxr-0004ap-JP; Thu, 19 Apr 2007 11:54:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYxp-0004aZ-HO; Thu, 19 Apr 2007 11:54:29 -0400
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYxm-00080j-3O; Thu, 19 Apr 2007 11:54:29 -0400
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA00774; Thu, 19 Apr 2007 17:54:16 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200704191552.l3JFqNWE008872@fs4113.wdf.sap.corp>
Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt
To: Nicolas.Williams@sun.com
Date: Thu, 19 Apr 2007 17:52:23 +0200
In-Reply-To: <20070419145614.GJ4375@Sun.COM> from "Nicolas Williams" at Apr 19, 7 09:56:15 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: kitten@lists.ietf.org, spkm@ietf.org
X-BeenThere: spkm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: Low Infrastructure Public Key GSS mechanism <spkm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/spkm>
List-Post: <mailto:spkm@ietf.org>
List-Help: <mailto:spkm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=subscribe>
Errors-To: spkm-bounces@ietf.org

Nicolas Williams wrote:
> 
> On Thu, Apr 19, 2007 at 04:16:16PM +0200, Martin Rex wrote:
> > Nicolas Williams wrote:
> > > I can't tell if RFC2478/4178 require that header on non-initial SPNEGO
> > > context tokens, but our implementation does NOT put it on any SPNEGO
> > > context token other than the initial one.  Did we miss this?
> > 
> > > 
> > > This requirement, if we wanted to make it, would have to apply only to
> > > future Standards-Track mechs.
> > 
> > That requirement *DID* exist in rfc-2478.  So there seems to be
> > a completely backwards incompatible change in rfc-4178.
> > At least rfc-4178 is very explicit what it wants in 4.2.
> > 
 [...]
> > I thought there was an interop of SPNEGO-implementations a while ago--
> > I would have expected this issue to become apparent if it was ambiguous,
> > provided that there are truely independent implementations of _the_spec_.
> 
> There truly independent implementations of _RFC4178_ were tested.

As I said, rfc-4178 is very explicit what it wants in section 4.2.
and this fact is highly appreciated.

I would have expected this backwards incompatible change to become
apparent when interop-testing backwards compatibility with exiting
(i.e. legacy) implementations of SPNEGO.  SPNEGO started out as SNEGO (without
the handshake protection and without the optimistic token), and
IIRC there (once) was a sample implementation of SNEGO by Bull
announced by Denis Pinkas:

  From: pinkas@emsc.frcl.bull.fr (Denis Pinkas)
  Message-Id: <9602271637.AA23945@emsc.frcl.bull.fr>
  Subject: Simple GSS-API negotiation available
  To: cat-ietf@mit.edu (IETF CAT WG)
  Date: Tue, 27 Feb 1996 17:37:43 +0100 (NFT)

  An implementation of the Simple GSS-API negotiation mechanism
  (Internet-Draft draft-ietf-cat-snego-01.txt, 19 February 1996)
  is now available at the following URL :

      ftp://ftp.enst-bretagne.fr/pub/security/gssneg.tar.gz

  It uses SNACC 1.1 libraries for encoding and decoding of PDUs
  described in ASN.1. The SNACC compiler can be found at:

 
Unfortunately, that "reference" implementation appears to be
no longer available anywhere.


Anyway -- there seemed to be very few independent implementations
of rfc-2478 and only one implementation with a significant installed
base.  Personally, I never liked SPNEGO, and the claimed abiguities
in rfc-2748 seemed to cause a certain amount of interoperability
problems anyway, so I think it is OK if rfc-4178 prefers interoperability
with a significant installed base to interoperability with rfc-2478.


When a feature of a revised spec is significantly clarified over the
previous version of the spec, a backwards interoperability warning
should be added.  This is missing in rfc-4178 4.2.


-Martin








_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm