Finally getting to this... > You might be able to make a new context and use > krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(), > krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to > copy the keys. I don't think rd_priv and mk_priv use anything else in > this configuration.
I think I want the _k versions of the set functions, no? It looks like the gets malloc a block, so the sets can just set and ref it, right? Hmm, no, it looks like create_key also copies the data. Is there any way to not do the wasted extra malloc? It looks like krb5_key_st is opaque, so I can't ref it and then use that to copy the keyblock even. In other words, I want to get the keyblocks with the current API, but then set the pointers without another call to krb5int_c_copy_keyblock. I guess I could make a couple new APIs since this is all linked statically in my app... Chris On 2015-05-08 08:41, Greg Hudson wrote: > On 05/08/2015 04:57 AM, Chris Hecker wrote: >> Hmm, thinking about this a bit more: if I turn off DO_SEQUENCE so I can >> share the auth_context, is there a way to dupe it so it can be used in >> both threads simultaneously? There shouldn't be any more mutable >> dependent state in there if there's no seq being used, right? > > You might be able to make a new context and use > krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(), > krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to copy > the keys. I don't think rd_priv and mk_priv use anything else in this > configuration. > > (Don't use the _k variants; they use reference counts rather than > copying, and krb5_keys are mutable and not internally locked..) > > Also, in addition to all of the attacks I mentioned for this auth > context configuration, reflection attacks are possible, where a message > from A to B is reflected back to A masquerading as a message from B. > You'll need to make sure to take that into account in your protocol, > perhaps just by making client-to-server messages look different from > server-to-client messages. > . > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos