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

[Chris Hecker]

> I think you mean AP-REQ/AP-REP.

Ah, yeah, sorry, it's been a while since I've had to mess with kerberos 
(once I got it working) so I'd paged out all the learning from a couple 
years back.  :)

>> Basically, in my tests I've found the initial AS_REQ authentication
>> is pretty slow
> Perhaps due to a replay cache?

Nope, I've got the replay cache turned off and always have.

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.

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?

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?

Thanks!
Chris

On 2015-05-07 08:17, Greg Hudson wrote:
> On 05/07/2015 05:54 AM, Chris Hecker wrote:
>> Okay, I have a client communicating with a server, and they've gone
>> through the AS_REQ/AS_REP dance and that's all working fine.
>
> I think you mean AP-REQ/AP-REP.
>
>> Basically, in my tests I've found the initial AS_REQ authentication is
>> pretty slow
>
> Perhaps due to a replay cache?  You can turn that off, if your protocol
> doesn't need it.  Basically, the protocol needs to ensure that the
> server sends something that affects what the client needs to send in
> order to make anything happen.  This could be as simple as a random
> challenge which the client has to echo back.
>
>> I don't think I could use the same auth_context in the second thread
>> (even with a mutex) because I don't know which order things will come
>> in, and I'm using DO_SEQUENCE so I think the mk_priv/rd_priv pairs have
>> to happen in order, which I can't guarantee with another thread.
>
> Yes, you would need a mutex (krb5_auth_context is not internally locked)
> and you would need to turn off DO_SEQUENCE, which would mean your
> protocol would have to address replay, reordering, and message
> suppression attacks.  Also attacks where messages from one flow are
> inserted into a different flow using the same auth context.
>