de facto inline mutual auth via krb5_mk_req / krb5_rd_req?
tcz3 at cornell.edu
Thu Feb 14 12:19:00 EST 2002
In the process of porting our low-level stateless protocol libraries from
K4 to K5, I've had trouble preserving the notion of inline mutual auth that
was tailored to krb4's use of explicit integer checksums in the AP_REQ
calls. In the krb4 version, the dataflow was:
client generates int_32 'mutual' from time()
client calls krb_mk_req, providing 'mutual' as 5th arg
----authdat blob is passed to server through library protocol from client----
server calls krb_rd_req, pulls 'mutual' from checksum member of AUTH_DAT
server increments 'mutual', calls krb_mk_priv with this checksum as the inbuf
----authdat blob is passed back to client through library protocol from
client calls krb_rd_priv and verifies that decrypted outbuf is checkum +1
In translating this to krb5, while the mk_priv and rd_priv are
straightforward, I have not been able to fathom the analog for mk_req and
rd_req. I'm basically looking for any piece of data, preferably a long
number but maybe a short char* glob, that can be "known" by both client and
server after their krb5_mk_req() and krb5_rd_req() calls are made,
respectively. I do not want to create any other network exchange other than
the 2 above, due to the nature of our specific protocol.
I initially thought the krb5_authenticator (as authentp member of auth
context) would contain this info, but a call to
krb5_auth_con_getauthenticator() after a krb5_mk_req() will seg fault,
because the 'client', 'checksum', and 'authorization_data' members of the
authenticator are explicitly nulled out within the mk_req_call (and
auth_con_get_authenticator calls copy_authenticator which expects data in
the client field when it does its memset), so I have no way for the client
to recover anything there to store locally after it is done krb5_mk_req()
and has the AP_REQ blob.
I also tried just doing myAuthContext->authentp->ctime on both sides, but
the struct definition of krb5_auth_context is hidden outside of the API
headers, and I don't want the unkosher effects of trying to duplicate it
locally for a dubious pointer dereferencing.
I'm also experimenting with providing some token in_data to krb5_mk_req(),
but I can't quite figure out what happens to it on the other side when
krb5_rd_req() is done. The src for krb_mk_req_extended() appears to only
use it for generating the checksum binary (which it then nulls out locally)
for the authdat blob. Is there any way to decrypt/recover the "in_data" in
the krb5_ticket struct that comes out of krb5_rd_req? Or do I have another
way of getting at the checksum locally by calling an explicit decryption of
the blob before sending it out, the same checksum the server will have when
it is done rd_req?
Let me know your ideas...
More information about the krbdev