[1339] in Kerberos-V5-bugs
Re: Possible protocol change found in Krb5 Beta 4 flags encoding.
daemon@ATHENA.MIT.EDU (John J. Marco)
Tue Apr 18 21:51:02 1995
From: "John J. Marco" <johnma@sco.COM>
To: tytso@MIT.EDU
Cc: krb5-bugs@MIT.EDU, dceivers@sco.COM
Date: Tue, 18 Apr 1995 18:48:51 -0700 (PDT)
Thank you for your quick response to my email.
Please see below....
> Date: Tue, 18 Apr 1995 20:45:40 +0500
> From: Theodore Ts'o <tytso@MIT.EDU>
> To: "John J. Marco" <johnma@sco.COM>
> Cc: krb5-bugs@MIT.EDU, dceivers@sco.COM, johnma@sco.COM
> In-Reply-To: John J. Marco's message of Fri, 14 Apr 1995 17:27:04 -0700 (PDT),
> <9504141727.aa02140@lubyanka.pdev.sco.COM>
>
> From: "John J. Marco" <johnma@sco.COM>
> Date: Fri, 14 Apr 1995 17:27:04 -0700 (PDT)
>
> The change:
> -----------
> I looked at the code for two ASN.1 compiler based releases:
> The OSF/DCE Kerberos code, based on the DCE Mavros compiler
> The MIT V5 Beta4 ISODE/Pepsy based asn.1 code (now obsolete).
> Both of the above implementations __Reverse__ the bit order of KRB5 flags
> fields before passing them down the the ASN.1 encoder. This is done in
> the following source files:
> MIT/ISODE based: src/lib/krb5/asn.1/cvt_flags.c
> OSF/DCE mavros: src/security/krb5/lib/mvr/krb5-manual-glue.c
> The relevant thing to look for is the "swbits" array, used as a function
> to reverse the bit order in a byte.
>
> The MIT Krb5 Beta4 hand-coded asn.1 encoder does not appear to have any
> code in it to reverse the bit order.
>
> You are correct; this is a bug in the the hand-coded encoder and
> decoder. The bug was caused by one of original implementers, who
> believed that, bit 0 should be the msb, and encoded the bit fields in
> the fieldbits.h include file that way. This has several problems,
> including the fact that it's not terribly portable to non-32 bit
> architectures, and it's exactly opposite to what the ASN.1 code demands.
>
> When we did the hand-coded encoder, we missed this little curve ball
> which said original implementer left behind for us, so we ommitted the
> bit reversal.
>
> The right way of fixing this is to reverse the bits in the fieldbits.h
> file, so the bit reversal is no longer necessary. The fact that we
> needed to do the bit reversal at all was fundamentally broken part in
> the original code. (This should explain your confusion about why the
> bit reversal was being done; it was through our own bone-headedness.
> It's quite correct that that ASN.1 doesn't require the bit reversal.)
>
> We can fix the interoperability problem to a small degree by causing the
> decoder to check to see if the high 16 bits are set, and if so, doing a
> bit reversal. This will fix the rlogin program in that a new server
> will be able to accept connections from either old or new clients.
> Unfortunately, since the TicketFlags bit string is communicated to the
> client and stored in the ticket cache, it will be difficult if not
> impossible to completely fix the interoperability problem in that case.
The fix we are considering is to put a hacked version of recvauth() in
rlogin, rsh, etc. This version of recvauth will check both bit orders for
the mutual auth. flag. This fix is acceptable for us since our shared Kerberos
library is only used for our runtime tools. We don't make this Kerberos
environment available to developers at this time and we don't want to rebuild
the whole library.
>
>
> Thank you very much for calling this serious problem to my attention!!
> Fortunately, most of the Kerberos code that is being shipped by vendors,
> do not, as far as I know, have this problem; we caught this problem
> before most vendors had a chance to incorporate this code in their
> products. May I forward your message to krb5-bugs to the Kerberos
> mailing list, along with my response? I believe it is important that
> everyone know about this problem as soon as possible. (With any luck, I
> will also include some patches which will help ameliorate the
> interoperability problems.)
Yes, you may post the message to the Kerberos mailing list.
Should I take the above statement to mean that few vendors are using
pre-beta4 code, or does it mean that few vendors are using the beta4
code? Also, what is now the "official" Kerberos V5 protocol encoding
of bitfields. I would assume that the Beta4 (no bit reversal) encoding
will become the "correct" encoding, since it matches with rfc1510's
requirement of using ASN.1+BER+DER encoding.
At least one vendor's Kerberized MS Windows client does not interoperate
with our rlogind because their client code behaves like Beta4 (and probably
is beta4) and does not flip the bits. Our code is based on an older
release that does reverse the bit order.
>
> - Ted
Thanks.
------------------------------
John Marco
The Santa Cruz Operation, Inc.
(408) 427-7638 johnma@sco.COM
------------------------------
