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