directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Kerberos flags processing issues
Date Mon, 22 Nov 2010 12:16:56 GMT
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 :
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.

This extra byte defining the number of unused bits is used for 
applications sending an undefined number of bits. Not very useful...

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...

Emmanuel L├ęcharny

View raw message