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
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
