[5020] in Kerberos
FALSE ALARM: SEVERE interoperability bug in Kerberos V5 beta 4
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Sat Apr 22 12:52:51 1995
Date: Sat, 22 Apr 1995 12:40:53 -0400
From: "Theodore Ts'o" <tytso@MIT.EDU>
To: kerberos@MIT.EDU
Cc: johnma@sco.COM, mbrowder@sco.COM, dceivers@sco.COM
Cc: "Richard B. Ward" <richardw@microsoft.com>, suchang@microsoft.com
Mea culpa. It turns out that the interoperability bug which I had
announced to the Kerberos list wasn't really a problem after all.
I received a user bug report claiming that the bit ordering between the
Krb5 Beta 4 using the hand-coded parsers was backwards compared to that
generated by the Krb5 Beta 4 using ISODE, and also from the OSF/DCE. I
looked, and saw that the ISODE glue code had a bit reversal algorithm in
it, which our code didn't, and then when I tried to read the ASN.1
specifications, I got confused and interpreted them wrong. Sorry for
spawning the confusion.
Over the weekend, I pulled out a older snapshot of our sources from CVS,
and compiled a version of the Kerberos library using the ISODE
libraries, and ran it against our test suites, and as well as analyzed
the code. I also spent quite a bit of time meditating over the ASN.1
specifications.
Bottom line: the Beta 4 implementation as released using ISODE asn.1
routines and the hand-coded parser routines, are generating the same
output --- and as to my best understanding of the ASN.1 specifications
and RFC-1510, the Beta 4 implementation is conformant with regards to
the ordering of the bit strings as defined RFC-1510. Hence, people
should *not* apply the patch which I sent out over the last two days. I
apologize for the confusion. I should have done some more checking and
gotten hard confirmation before sending out my announcement.
I can't personally confirm whether or not the OSF DCE implemenatation is
encoding ticket flags the same way the Beta 4 ISODE specifications
details it; but I received many reports, from differing sources, that
requests between the OSF DCE and our old ISODE parsers do work
correctly. Hence I have no reason to believe that the OSF/DCE
implementation is doing anything different. Hence, I now believe that
the OSF/DCE implemenataion using the Mavros ASN.1 compiler, the MIT
implementation using the ISODE ASN.1 compiler, and the MIT
implementation using the hand-coded parsers, are all generating KRB5
flags in the same manner, consistent with RFC-1510 and the ASN.1 specs.
Now, since people *are* trying to implement their own hand-coded
parsers, let me share with you what I believe to be the correct ASN.1
encoding of the KDC Options bit strings --- and which (as far as I can
tell) the MIT implementations have always generated:
--------------------------------------------------------------------------
The FORWARDABLE bit is defined to be bit #1 (starting with a numbering
scheme starting at 0, which is what RFC-1510 uses. This is somewhat
confusing, since at least some ASN.1 descriptions use a numbering scheme
starting with 1 instead of 0.) in an ASN.1 BIT STRING. Similarly the
INITIAL bit is defined to be bit #9.
[Something which is *not* specified in RFC is the length of this BIT
STRING. However, what the MIT and OSF/DCE implementations both do is to
always emit a BIT STRING that is 32 bits long. For interoperability
reasons, it would be wise for other implementations to also emit such
encodings --- but it is valid for an implementation to emit a BIT STRING
that is only 2 bits long; not all implementations will accept this, but
a well-written one implementation should. ("Be conservative in what you
send, liberal in what you accept.")]
So, a Ticket Flags BIT STRING which has both the FORWARDABLE bit (bit #1)
and INITIAL bit (bit #9) set looks like this:
0 1 2 3
Bit #: 01234567890123456789012345678901
Encoding: 01000000010000000000000000000000
Now, the the ASN.1 BIT STRING encoding of "01000000010000000000000000000000"
is to take the bits and put them into octets, STARTING AT BIT 8 AND
MOVING ON TO BIT 1, so that the first bit of the bit string is in the
most significant bit of the first octet, and the 9th bit of the
bitstring is most significant bit of the second octet, and so on.
Hence, we take the above bit string and break it into 8 bit chunks:
01000000 01000000 00000000 00000000
0x40 0x40 0x00 0x00
You then add on the ASN.1 header for a BIT STRING type (03 05) and the
number of excess padding bits (which is zero, since 32 is a multiple of
8), and you come up with the final result which is:
03 05 00 40 40 00 00
Another encoding which is also valid for a Ticket Flags field encoding
the INITIAL and FORWARDABLE bits is:
03 03 06 40 40
(i.e., this is an encoding of a bit string of length 10: "0100000001")
Implementations MUST be prepared to accept this encodings like this,
but they SHOULD not send it, in the interests of interoperability.
Implementations SHOULD also be prepared to accept bit strings longer
than 32 bits, although no bit beyond bit #31 are currently defined in
the Kerberos specification, so any bits beyond #31 should be zero, if
they are sent.
--------------------------------------------------------------------------
As for why there was a bit reversal code in the ISODE glue layer, and
not our hand-coded parsers? That's because the ISODE library does a bit
reversal operation inside its guts, and so the glue layer code had to do
*another* bit reveral in order to set things straight again. So while
we were using the ISODE asn.1 library in Kerberos, the flags field was
getting flipped back and forth needlessly --- which is one of the
reasons why using the hand-coded parsers is a good idea.
In any case, I apologize for any confusion which resulted from my
posting of a problem that turned out not to be a problem after all!
Lessons learned from this? (1) Never trust anything contained in a bug
report until you can verify it for yourself, personally. (2) Trust your
test suites. (3) Using ASN.1 in a protocol design is a mistake. Its
abstractness gets in the way of people understanding what the wire
protocol really looks like; it gets in the way of a protocol being
compact (encoding a date is a factor of four more expensive); it gets in
the way of validating a protocol. Given all of the problems we've had
with asn.1, my practical experience is that it's not worth the time,
effort, and complexity. Sigh. Well, at this point, hopefully we've
paid for most of the costs of using ASN.1 in the Kerberos V5 protocol
specification --- at least, I hope that's the case!!!!
- Ted
