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

[Chris Hecker]

> Hm, you might be able to speed this up by supplying the service key
> to the auth context with krb5_auth_con_setuseruserkey()

Just to be clear, this would be they "key" member of the 
krb5_keytab_entry struct, right?  I iterate the keytab already to get 
the princ, so I've got it sitting right there.  I'm already using this 
API for u2u authn, it turns out (which is what it's for, I'm assuming :).

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