> 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
