Does this separate thread connection need another as_req/rep pair?

[Chris Hecker]

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