Subject: reqFlags - ASN.1 comment out of sync with text (was Re: I-D ACTION:draft-ietf-kitten-2478bis-05.txt)

From: Simon Spero <[email-masked]>
Date: Wed, 02 Feb 2005 10:37:14 -0500

BTW, is there any reason why the initiator side is just 'SHOULD'?  Are 
there any valid reasons for a new implementation to include this?

Text :
   reqFlags

         This field, if present, contains the service options that are
         requested to establish the context (the req_flags parameter of
         GSS_Init_sec_context()).  This field is inherited from RFC 2478
         and it is not integrity protected.  For implementations of this
         specification the initiator SHOULD omit this reqFlags field,
         and the acceptor MUST ignore this reqFlags field.

ASN.1:
...
           reqFlags        [1] ContextFlags  OPTIONAL,
             -- inherited from RFC 2478 for backward compatibility,
             -- RECOMMENDED to be left out
...
---------------
Fix:

	reqFlags [1] ContextFlags OPTIONAL
	-- inherited from RFC 2478 for backward compatibility
	-- initiator SHOULD omit
	-- acceptor MUST ignore

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Feb 2005 23:50:23 +0100 (MET)

> there any valid reasons for a new implementation to include this?

Actually, the "acceptor MUST ignore" is inappropriate procedurally,
it ought to be a SHOULD.

If there was a feature in a predecessor spec on the standards track,
then the revision of the spec may deprecate that feature and
discourage it use, but it should not outlaw its use entirely
(except maybe for exceptional cases, but that doesn't apply here).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Feb 2005 11:53:37 -0600

> (except maybe for exceptional cases, but that doesn't apply here).

There was nothing (see below) that an acceptor could have done with that
field, so deprecating it is entirely appropriate.

RFC2478 said nothing about what an acceptor should or could do with
reqFlags nor is there an obvious handling for that field in the context
of the GSS-API (GSS_Accept_sec_context() lacks a flags input parameter).
(But see below.)

And there's probably no obvious acceptor disposition for that field for
acceptors implemented using non-GSS interfaces (e.g., the SSPI) to GSS
mechanisms.

Sure, an acceptor might compare reqFlags to ret_flags from
GSS_Accept_sec_context() and return an error if the context did not
provide some feature requested by the initiatior.  But rfc2478 is quite
silent on this matter and provides no suitable major/minor status code
to return in such situations.  And such behaviour might be rather
surprising -- and unnecessary to boot since both peers get a ret_flags
out of the mech context (it would as surprising if a mechanism produced
different ret_flags for the two peers of a context; I don't recall if
such behaviour is allowed by RFC2743, but in any case, the application
would no doubt notice).

What conclusion can we reach other than that either the spec was
incomplete with regards to reqFlags or that reqFlags was a bug in the
spec, such that we can now deprecate it safely?

If there is some desirable acceptor handling of reqFlags other than
ignoring it (is there?) we could specifiy that instead of deprecating
that field.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Feb 2005 12:24:37 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Simon Spero wrote:
    >>  BTW, is there any reason why the initiator side is just
    >> 'SHOULD'?  Are there any valid reasons for a new implementation
    >> to include this?

    Martin> Actually, the "acceptor MUST ignore" is inappropriate
    Martin> procedurally, it ought to be a SHOULD.

    Martin> If there was a feature in a predecessor spec on the
    Martin> standards track, then the revision of the spec may
    Martin> deprecate that feature and discourage it use, but it
    Martin> should not outlaw its use entirely (except maybe for
    Martin> exceptional cases, but that doesn't apply here).

One of the common cases where this is appropriate is when a security
problem is discovered.  "Foo should have been integrity protected and
is not," is an example of such a case.

As such I think a MUST is entirely appropriate from a procedural
standpoint.  A SHOULd is also OK from a procedural standpoint.