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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
