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

Chris Hecker checker at d6.com
Fri May 8 04:57:29 EDT 2015


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?

Chris
On May 7, 2015 2:22 PM, "Chris Hecker" <checker at d6.com> wrote:

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


More information about the Kerberos mailing list