Hi guys,
here is a little summary of the way Kerberos Flags should be handled,
and may explain why we now have problems with the current tests, when it
was working 3 weeks ago.
Basically, Kerberos flags are BITSTRING, an ASN.1 generic type, which
stores bit fields. As Kerberos first implementers misunderstood the way
ASN.1 DER encoding should have worked, the latest Kerberos RFC have
requested that the ASN.1 DER encoding for BITSTRING to be less stict
than it should.
A BISTRING DER encoded should normally be stored in with as few bytes as
necessary to store all the bits up to the last '1'. Bits are also stored
from left to right, where the left bit is the lower weight bit. It's the
opposite to what we are used to, but it's just a convention. So if we
have 32 possible boolean flags, from 0 to 32, then the flag #0 is stored
on the left, the flag #1 is stored on the next position, etc :
[#0 #1 #2... #7] - [#8 ...
first byte.........second byte....
That being said, in DER, if we have 32 boolean flags, and if the flag #3
is set to 1, and all the other flags are set to 0, then we will spare 3
bytes by encoding only the first byte this way :
0010-0000
all the other bits being 0. We save 3 bytes ! Big deal... Anyway, the
problem here is that The ASN.1 DER/BER encoder adds an extra byte to
tell the decoder how many bits are just irrelevant on the right. As we
have 32 bits, in our case, this extra byte is *always* 0 for Kerberos.
This is where Kerberos is less strict than the DER encoding dictate : we
should accept a PDU containing 5 bytes, even if all the bits are 0, when
in DER encoding, this would be encoded as an empty BITSRING.
<note>
This extra byte defining the number of unused bits is used for
applications sending an undefined number of bits. Not very useful...
</note>
Anyway, we now have to deal with this extra (useless in our case) byte,
which will always be 0x00 for us.
The KerberosFlags is extending BitString which is probably a wrong idea.
I don't see any added value this has, and I think I made the wrong call
when I decided to do that. This is bad because we are mixing concerns
here : the value manipulated by the Kerberos Server and the codec value.
We should instead use a converter to switch from an int (32 bits in
Java) used inside teh server and the codec representation (BIT STRING),
used only when encoding or decoding.
That would probably make the whole prolem vanish magically...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
