[1340] in Kerberos-V5-bugs
Re: Possible protocol change found in Krb5 Beta 4 flags encoding.
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Apr 18 22:34:57 1995
Date: Tue, 18 Apr 1995 22:34:47 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: "John J. Marco" <johnma@sco.COM>
Cc: krb5-bugs@MIT.EDU, dceivers@sco.COM
In-Reply-To: John J. Marco's message of Tue, 18 Apr 1995 18:48:51 -0700 (PDT),
<9504181848.aa01602@lubyanka.pdev.sco.COM>
From: "John J. Marco" <johnma@sco.COM>
Date: Tue, 18 Apr 1995 18:48:51 -0700 (PDT)
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.
This will certainly fix the AP-Opts problem; the hard one is fixing
TicketFlags interoperability one. One can put in a fixed KDC which
check both bit orders which will allow the user to get a forwardable
ticket. However, programs that actually check the forwardable flag will
get confused, since that byte order will still be backwards for them. I
*think* the only casualty is "klist -f", but I haven't done a detailed
impact analysis.
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.
No, the Beta 4 encoding is *not* the correct encoding. If you look at
RFC1510, you will see that the forwardable bit is #1; however, in beta
4, the fieldbits.h file defined KDC_OPT_FORWARDABLE as:
#define KDC_OPT_FORWARDABLE 0x40000000
The ASN.1+BER+DER encoding of bit #1 (alone) in a 32 bit field is
defined to be
03 05 00 02 00 00 00
| | | |
| | | +------ bit #1 encoded
| | |
| | +--------- pad count == 0
| |
| +------------ length == 4 bytes, plus pad count
|
+--------------- type == BIT STRING
The problem is that the values in fieldbits.h are *backwards*, because
the person who created that file believed that bit #0, should be the
most significant bit. The glue code had to reverse the encoding because
the values in fieldbits.h are reversed.
Hence, the encoding used by the ISODE and OSF/Mavros implementation are
correct, and the one generated with Beta 4 (with ISODE turned off) is
INCORRECT.
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.
That's bad; I didn't realize some vendor had released a Kerberized
Windows client based on beta 4 code. Can you tell which client it is?
They should be alerted to this problem.
- Ted
