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

From: Tom Yu <[email-masked]>
Date: Fri, 03 Oct 2003 00:30:57 -0400

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: Thu, 09 Oct 2003 22:09:12 -0400

As I said, most of these are fairly minor things...

Section 1:

Next to last paragraph: I don't think this is a great description.
How would you classify RC4 based on this?  An I-D came out, but no RFC
yet.  I would hope that if an RFC came out now, it would be in terms
of a kcrypto profile.  So, if you get an RC4 session key, should you
assume support for CFX, or the Microsoft RC4 mechanism extension?
(And how about 3DES?  The write-up I did on MIT's extension never
became an RFC.)  Maybe better would be to list the types that are not
supported this way.

Section 2:

If the acceptor specifies a subkey, and the initiator is thus required
to start using it on receipt, under what circumstances should/may the
acceptor start flagging as errors tokens received without the
AcceptorSubkey flag set?

Section 3:

First paragraph: "applications which use the default QOP are not
guaranteed to be portable across implementations..."; shouldn't this
be applications which *don't* use the default?

Section 4.1.1.2:

If this is, as I suspect, merely a clarification of RFC 1964, and not
actually different from what interoperable RFC 1964 implementations
are doing, please mention that.

Section 4.2.1:

With the sequence number and direction indicator now no longer in the
same field, there is no logical reason to combine their descriptions
into one section when the other fields are described in separate
sections.  They should all be described in separate sections.

Sections 4.2.4 and 4.2.6.x:

The draft repeatedly refers to "the checksum operation defined in the
crypto profile" and similar phrases.  The crypto framework, or rather
a profile based on it, does not specify a unique checksum type that
must be used with a given encryption type.  It does, however, specify
a checksum type that is mandatory to implement if the encryption type
is supported.  In general, there is no reason a des-cbc-md5 encryption
key cannot be used to make an rsa-md4-des checksum, if it is known
that the receiver supports the latter.  It's because of the lack of
negotiation or any field for specifying the checksum type that the
cfx-02 mechanism chooses to always use the required checksum type.

Sections 4.2.4, 4.2.6.1 and 4.2.6.2:

I think the Wrap-without-confidentiality and MIC tokens should order
the header and application data fields the same way.  Otherwise, an
attacker who can force one application message to contain

	<fake-MIC-header> <stuff>

may be able to then construct a MIC token over an application message
containing

	<stuff2> <fake-Wrap-header>

if the cryptosystem in use is one for which the key usage number does
not actually perturb the encryption.  (We couldn't require that,
remember, because we need DES to be conformant.)

Section 4.2.5:

Since there's no prohibition against a non-zero RRC in Wrap tokens
without confidentiality, I'll plan to exercise that in the MIT code.

Section 4.2.4, 4.2.6.2:

In the wrap-with-confidentiality case, "filler" is used to describe
two different things, an octet field in the token header, and an
optional insert between the application data and the copy of the token
header.  Perhaps a different word could be used for one of the two
cases?

Section 6:

What does "use of Kerberos Version 5 extensions" mean?  I think I know
what you mean by it, but the spec should be useful to an implementor
(now, or 10 years in the future) who isn't keeping tabs on the working
group discussions.

Section 9.1:

Fix the typo ("Kerveros") and the author list for [KRBCLAR].  (Of
course, we'll have to wait for it and the other drafts to go to RFC
before cfx can, so updates will be needed for that reason also.)

Sorry, I still haven't gotten to looking at the error codes yet.

As for the "generic token framing" thread, I've got no strong opinion,
except that Martin's suggestion to reserve the token-id ranges that
would correspond to the wrapper, if we don't always use the wrapper,
is a good one.  I had some concerns about that when dropping the
framing was first suggested, but never investigated.

Ken