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

[Greg Hudson]

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.