Subject: RE: invalid ASN.1 in gssapi-cfx-02

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 3 Oct 2003 15:38:47 -0700

Tom Yu wrote:

>> In section 4.1, the initial context token ASN.1 from RFC 2743 is
>> included by value.  Granted, RFC 1964 does this as well, but there is
>> no good reason to perpetuate the error.  I believe we should remove
>> this by-value inclusion from the draft, and probably replace it with
a
>> reference to section 3.1 of RFC 2743.

I beg to disagree with this portion of your comment. Here are the
reasons:

1) The paragraph of 4.1 of this draft is "instantiation" rather than
"reference by value" of 3.1 of RFC 2743.  As you have noticed, the text
in 4.1 of this draft is substantially different from that of RFC 2743.
The differences are mainly because 2743 is meant to mechanism
independent, thus it has texts that only make sense there, while this
draft describes the Kerberos and only the Kerberos mechanism.
 
2) The most noticeable evidence of "instantiation" is that 2743 says
initial tokens must use the pseudo ASN.1 header and the use of such
header is optional for everything else, while in this draft, all initial
tokens MUST use the pseudo ASN.1 header, and per-message and context
deletion SHALL NOT use this header. Another example is that in this
draft we use TOK_ID, while in 2743 how to distinguish initial and
per-message tokens is up to individual mechanisms. For these reasons, we
can not say the framing here is simply the RFC 2743 token framing (but
the former is compatible with the later).

3) There is still some ambiguity left in this draft, this was because we
do not want user2user being non-compatible with this draft while we do
not have time to specify it fully here, but even that might not be
relevant, since in off-list discussions with Nicolas, Sam, Ken and JK, I
at least proposed another user2user-alike mechanism to force 1 and 1/2
round-trips by the acceptor.

4) I personally do not think "by reference" is applicable to this
Kerberos V5 GSS-API mechanism.  You can use "by reference" if you afford
the value/context that you refer to can change.  That is not the case
here; any change of 2743 probably will necessitate an update of this
draft.  If we were using "by reference", we would have added some text
in the security consideration and backward compatibility sections, which
is not something I would prefer to do.  For these reason, I think "by
reference" should be used with discretion.

>> RFC 2743 uses ASN.1 to illustrate the semantic content of the initial
>> context token, not to specify its encoding.  RFC 2743 explicitly
>> describes the actual encoding of the initial context token at the
>> octet level.  The described encoding is very similar to the ASN.1 DER
>> (and identical for all practical purposes).  Unfortunately, the ASN.1
>> in RFC 2743 is invalid, even by the obsolete 1988 version of the
ASN.1
>> specification (X.208).

You are absolutely correct here. Neither we nor RFC 2743 claim that the
description of the token framing is in ASN.1 syntax, rather we say it is
a "pseudo" ASN.1 header.  The reader need to look up 3.1 of 2743 in
order to understand how the encoding really works.  Just like it does
not make sense to parse "C-alike" pseudo algorithm descriptions with C
syntax, the description in 4.1 of this draft does not need to ASN.1
parse-able.

The most controversial portion here is the use of "ANY" without
explanation in RFC 2743 to back it up.  But I did not think that was
fatal, if you do, please let me know. 

Thanks, 

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tom Yu
Sent: Thursday, October 02, 2003 9:31 PM
To: [email-masked]
Subject: invalid ASN.1 in gssapi-cfx-02

In section 4.1, the initial context token ASN.1 from RFC 2743 is
included by value.  Granted, RFC 1964 does this as well, but there is
no good reason to perpetuate the error.  I believe we should remove
this by-value inclusion from the draft, and probably replace it with a
reference to section 3.1 of RFC 2743.

RFC 2743 uses ASN.1 to illustrate the semantic content of the initial
context token, not to specify its encoding.  RFC 2743 explicitly
describes the actual encoding of the initial context token at the
octet level.  The described encoding is very similar to the ASN.1 DER
(and identical for all practical purposes).  Unfortunately, the ASN.1
in RFC 2743 is invalid, even by the obsolete 1988 version of the ASN.1
specification (X.208).

The ANY type is equivalent to a CHOICE type with unspecified
components (X.208 section 3.29); it is invalid to use non-ASN.1 types
in an ANY type, as RFC 1964 and this draft do.  It is misleading to
assert that the invalid ASN.1 copied from RFC 2743 constitutes the
framing for the tokens in the Kerberos GSS mechanism.  We should
instead reference the concrete encoding procedures in section 3.1 of
RFC 2743.

[Other parts of the ASN.1 in RFC 2743 don't parse at all,
incidentally.]

---Tom

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 03 Oct 2003 18:56:49 -0400

"Liqiang(Larry) Zhu" <[email-masked]> writes:
> draft.

RFCs don't change.  RFC 2743 will never change.  A reference to it
won't change meaning out from under us.

It's possible that there may be updates to the specification or it may
be made obsolete by some new RFC; if that happens, the reference Tom
is suggesting would still be to 2743, not "RFC 2743 or whatever
replaces it", regardless of how fast and loose we're trying to play
with that in other work.

Ken