[36973] in Kerberos
Re: Does this separate thread connection need another as_req/rep pair?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri May 8 11:43:25 2015
Message-ID: <554CD92F.1020808@mit.edu>
Date: Fri, 08 May 2015 11:41:35 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Chris Hecker <checker@d6.com>, kerberos@mit.edu
In-Reply-To: <CAOdMLc1dQr48W=p6yK8v21i=P1o=dEwCra7Dvej7SKV8Jj6h0A@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
