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

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> On Wed, Apr 18, 2007 at 11:03:55PM +0200, Martin Rex wrote:
> > > We should probably consider whether we want to RECOMMEND, or even
> > > REQUIRE that that header be added to all security context establishment
> > > tokens, not just the initial one.
> > > 
> > > But until somebody tables that matter we should not consider
> > > RFC1964/4121 as imposing such a requirement on other mechanism that use
> > > different mechanism OIDs.
> > 
> > Require, because it will amount to less code, less complexity and less
> > confusion.  The overhead is negligable.  I don't expect any implementation
> > of PKU2U to NOT provide rfc1964/rfc4121 functionality as well, despite
> > the seperate mechanism OID.
> 
> 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 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_.

In TLS it regularly happens that there is an early adopter of a new
feature and all others follow the lead instead of the spec, and as
a result breaking the spec in various subtle ways (i.e. I just noticed
that SSLv3 and TLS v1.0 prohibit the use of an empty CAlist in the
CertificatRequest message from the server, TLS v1.1 secretly changes
this in a backwards incompatible fashion without the slightest warning
and OpenSSL seems to have violated the SSLv3 and TLSv1 specs from the
beginning).



> 
> > > That said, there's this interesting question: PKU2U re-uses RFC4121 for
> > > everything following PKU2U's first two security context tokens (which
> > > are KDC messages between the initiator and the acceptor acting as a
> > > pseudo-KDC), so, should those context tokens lifted from RFC4121 bear
> > > this header?
> > 
> > I really want to see the generic framing on all context level tokens
> > (which is what you meant by header, I assume).
> 
> Yes, that's what I meant by 'header'.
> 
> > Could it be that you actually didn't want to ask about the framing,
> > but about the mechanism OID within the header (if it is present)?
> 
> No.
> 
> > I'd like to see the generic framing, and I'd like to see it with
> > the same mechanism OID as in the initial context token (which is
> > different from rfc1964/rfc2141).
> 
> Yes, if the generic header is on all context tokens then the same OID
> has to be used for all those context tokens for any given security
> context.
> 
> Nico
> -- 
> 


_______________________________________________
SPKM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/spkm