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

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.
> 
> Rfc2478 was always meant to use the generic framing on all context
> tokens (they're called "negotiation tokens").  It's true that this
> is not explicitly spelled out, but at the time when rfc-2478 was
> produced, both of the gss-api mechanism in the IETF/CAT discussion
> (rfc-1964 Kerberos 5, rfc-2025 SPKM) was using the generic framing
> on all of the tokens (context level AND per-message tokens), and
> the little words about the issue in rfc-2478:
> 
>   3.2.1. Syntax
> 
>      This section specifies the syntax of the corresponding
>      "innerContextToken" field for the first token and subsequent
>      negotiation tokens. During the mechanism negociation, the
>      "innerContextToken" field contains the ASN.1 structure
>      "NegociationToken" given below, encoded using the DER encoding
>      conventions.
> 
> talks about "innerContextToken" for the first **AND** subsequent
> negotiation tokens, which implies that all negotiation (=context level)
> tokens are built in the same fashion an all carry the generic framing.

I don't agree with that reading of the text.  Regardless, if there are
posts on the old CAT list about this saying that the generic framing is
expected on non-initial context tokens then I agree that RFC4178 made a
change.  But we can't all be reading mailing lists from years ago --
RFCs shouldn't miss such things, and RFC2478 was missing a lot of
details (e.g., what ASN.1 encoding to use).

> 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.

Nico
-- 

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