[36969] in Kerberos
Re: Does this separate thread connection need another as_req/rep pair?
daemon@ATHENA.MIT.EDU (Chris Hecker)
Thu May 7 17:23:02 2015
Message-ID: <554BD7A9.10505@d6.com>
Date: Thu, 07 May 2015 14:22:49 -0700
From: Chris Hecker <checker@d6.com>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>, "kerberos@mit.edu" <kerberos@mit.edu>
In-Reply-To: <554BB9D9.30807@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
> Hm, you might be able to speed this up by supplying the service key
> to the auth context with krb5_auth_con_setuseruserkey()
Cool, I'll check that out next time I'm optimizing, thanks!
Chris
On 2015-05-07 12:15, Greg Hudson wrote:
> On 05/07/2015 02:44 PM, Chris Hecker wrote:
>> I found it slow under a loadtest, where 1000s of clients were trying to
>> log in simultaneously. I can't find the profiles from before I
>> timesliced it, but on the (slow) machine I'm using it's looking like
>> it's taking 1ms for 6 krb5_rd_req calls, which means when thousands of
>> clients hit the server at the same time it's not great. The timeslicing
>> fixed it, clients just have to wait to get authenticated.
>
> Hm, you might be able to speed this up by supplying the service key to
> the auth context with krb5_auth_con_setuseruserkey() (poorly named for
> this purpose, but it works) so that krb5_rd_req() doesn't have to
> iterate through the keytab each time. Of course, it would then be up to
> you to notice when the keytab changes and grab the new key.
>
>> Okay, so with DO_SEQUENCE off and the mutex, it can be shared. I assume
>> for the same reasons, with DO_SEQUENCE off you can also use it on a UDP
>> (unreliable, ooo, etc.) connection?
>
> Yes.
>
>> By the way, for replay attacks, do I need to worry about cross session
>> replays (with the same TGT), or does every AP_REQ/AP_REP randomize so I
>> only need to worry about them for a single session?
>
> If you use KRB5_AUTH_CONTEXT_USE_SUBKEY on the server, then each auth
> context will use a different server-generated subkey, so you won't have
> to worry about cross-session replays--except for flows which share the
> same auth context, of course.
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
