[1334] in Kerberos-V5-bugs
Possible protocol change found in Krb5 Beta 4 flags encoding.
daemon@ATHENA.MIT.EDU (John J. Marco)
Fri Apr 14 20:28:18 1995
From: "John J. Marco" <johnma@sco.COM>
To: krb5-bugs@MIT.EDU
Cc: dceivers@sco.COM, johnma@sco.COM
Date: Fri, 14 Apr 1995 17:27:04 -0700 (PDT)
To Kerberos V5 support folks...
-------------------------------
I have discovered what appears to be a change in the Kerberos V5
wire protocol between the earlier ISODE/Pepsy based code and the
current Hand-coded-asn1 code in the V5 beta 4 release.
The change is in the encoding of at least two Krb5 flags fields which
are defined in the ASN.1 KRB5 definition as "BIT STRING" fields.
These fields are the "options" field of AP_REQ messages and the options
field AS_REQ messages. Actually, this change probably affects any
bit field sent over the wire.
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.
Result:
-------
The older versions of Kerberos transmit flags over the wire in reverse bit
order, while the latest code transmits flags without the reversal. This
breaks interoperability when flags are passed between a system with a Beta 4
kerberos library and one with an older Mavros or Pepsy based library.
Example 1:
----------
Kerberized rlogin is no longer interoperable between Beta 4 sites and older
sites. Here's why:
Case 1: beta 4 rlogin, non-beta4 rlogind:
The rlogin program initiates authentication by issuing a sendauth
command. This results in an AP_REQ message being sent to the
remote rlogind. The options field is set to AP_OPTS_MUTUAL_REQUIRED,
which is 0x20000000. Since rlogin is beta 4, it does not reverse
the bits, and just sends 0x20000000 to the encoder, which generates
"03 05 00 20 00 00 00" as the encoding for the options field.
At the other end, rlogind is based on the older MIT code, either
Beta 1, as in the case of the DCE code, or maybe beta 2, using
ISODE. In any case, rlogind receives the AP_REQ message, and the
encoder extracts the options field as 0x20000000 and passes it to
the "glue" layer. The glue layer then REVERSES THE BITS , and
stuffs 0x00000004 into the options field of the "krb5_ap_req"
data structure used by recvauth(). Recvauth checks for the
AP_OPTS_MUTUAL_REQUIRED bit by ANDing the options field with
its value (0x20000000). Since 0x04 is what actually got put
into this field, recvauth() does not send an AP_REP message. It
instead returns to the rlogind code, where rlogind then
waits in a read() for the client to send "lusername". Meanwhile
the rlogin client is also waiting in a read() for the AP_REP
message that it will never receive. The rlogin session is now hung.
Case 2: non-beta4 rlogin and beta4 rlogind.
This is the same problem as Case 1, except with different ends doing
the bit flipping. That is, rlogin now encodes the options field
(0x20000000) as "03 05 00 00 00 00 04" because it is not beta 4,
and it reverses the bit order. This gets passed to rlogind,
which IS beta4, and which does not reverse the bit order. The rlogind
decodes the options field to 0x00000004, and and the rlogin
session hangs as above.
Example 2:
----------
Same bit reversal problem as above, so I won't detail it. However,
this one involves the options field sent in a AS_REQ message.
Set up a V5 KDC that is based on ISODE or MAVROS. Set up a Kerberos
client host with V5 clients that are based on V5 Beta 4 without ISODE.
If you do a kinit without options, it works. However, if you
do "kinit -f" from the non-ISODE client, it fails and says that the
specified options could not be fulfilled.
Question:
---------
Which encoding is the correct encoding? It seems to me that the lack
of bit order reversal in the beta4 code may be an accidental ommission,
but it's hard to tell as the ASN.1 BER specification does not appear to
require bit order reversal. In fact, both the MAVROS and the PEPSY
compilers DO NOT reverse the bits. It is in the Kerberos application "glue"
layer that the reversal is done.
Why was this reversal done?
Any help or answers on this matter are appreciated.
Thanks.
------------------------------
John Marco
The Santa Cruz Operation, Inc.
Phone: (408) 427-7638
Email: johnma@sco.COM
------------------------------
