de facto inline mutual auth via krb5_mk_req / krb5_rd_req?

[Todd Zino]

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 
struct returned
server increments 'mutual', calls krb_mk_priv with this checksum as the inbuf

----authdat blob is passed back to client through library protocol from 
server-----

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

-Todd