Java Kadmin client

[Anderson Luiz Brunozi]

Hello,

I'm in the way of implementing a Java client for MIT Kerberos, including an admin client.
I already a working version, until I decided to change the cryptographic algoritm from DES to AES.
I have made this change, and can now authenticate users usings AES keys. After this change, i thought that it might have affected the admin client implementation, and so I started to revise that admin client code. But then I noticed that, according to RFC1964, the GSSAPI mechanism only supports DES, and so that code for the admin client should be still working (but it isn't anymore).
When migrating to AES, I also upgraded the Kerberos server from version 1.3.5 to version 1.4.1, and guess I haven't tested the admin client with the new kerberos version yet.

When testing my Java kerberos admin client (that has been implemented, in part, by analising kadm messages) with the MIT Kerberos 1.4.1, I got an error about the channel bindings. With the version 1.3.5, I could send null channel bindings and use GSSAPI_MSG_VERSION = 4. But, with 1.4.1, it looks like I can't do this. By looking at the code, it seems that only values 1 or 2 for GSSAPI_MSG_VERSION allow for null channel bindings.
Changing the GSSAPI_MSG_VERSION to use version 2, I'm now stuck at another problem: I receive a signed ISN that looks very diferent from what I have seem before, when implementing the client, by analising kadm messages exchanged beetwen a KIT kadmin client e the version 1.3.5 server. With this aproach I concluded that the signed ISN were encoded like any other GSSAPI message, but I'm getting values for signed ISNs like this:

05 04 05 ff 00 0c 00 00 00 00 00 00 22 d5 42 ce 
6b 8b 45 67 66 10 5f db 5a 47 63 8a 68 22 5d 81

Considering my first analisys of messages and what says RFC1964 (section 1.2.2), I would expect this to begin with something like:

02 01 02 00 00 00 FF FF...

I really have no idea on what to do with that "05 04 05 FF..."

I would really appreciate if anyone can tell me whether that have been changed on the new Kerberos versions, and if so, what have been changed, or where can I find some documentation on how to implement the client according the (supposed) new server implementation.
Or would the problem be the switching the value of GSSAPI_MSG_VERSION from 4 to 2? Does it affect the protocol in some way, other than the null channel bindings?

I know that it might be possible to do it by looking at the kerberos code, but is a hard way, as I have spent one day and almost no progress on this.

Thanks for any help,

    Anderson Luiz Brunozi