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