Does this separate thread connection need another as_req/rep pair?
checker at d6.com
Thu May 7 17:22:49 EDT 2015
> 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!
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?
>> 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.
More information about the Kerberos