Re: Does this separate thread connection need another as_req/rep pair?
On Sat, 20 Jun 2015, Chris Hecker wrote: > I think was unclear. I don't think there's a way to avoid a wasted > allocation here. I'm happy to have separate keys per thread, but there are > three keyblocks allocated in this scenario: there's the original, get > allocates a copy, set allocates a copy, then I have to free the one from > get because it's not used. There should be a version of set that takes > ownership of the memory, I think. Make sense? I do now understand what you were saying in a way that I did not before; thanks for the clarification. That said, I don't think that API should exist outside your personal fork, since it's only useful in specific cases and complicates the memory ownership story. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Does this separate thread connection need another as_req/rep pair?
I think was unclear. I don't think there's a way to avoid a wasted allocation here. I'm happy to have separate keys per thread, but there are three keyblocks allocated in this scenario: there's the original, get allocates a copy, set allocates a copy, then I have to free the one from get because it's not used. There should be a version of set that takes ownership of the memory, I think. Make sense? Chris On Sat, Jun 20, 2015 at 12:52 PM, Benjamin Kaduk wrote: > On Sat, 13 Jun 2015, Chris Hecker wrote: > > > > > Finally getting to this... > > > > > You might be able to make a new context and use > > > krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(), > > > krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to > > > copy the keys. I don't think rd_priv and mk_priv use anything else in > > > this configuration. > > > > I think I want the _k versions of the set functions, no? It looks like > > the gets malloc a block, so the sets can just set and ref it, right? > > Hmm, no, it looks like create_key also copies the data. Is there any > > way to not do the wasted extra malloc? It looks like krb5_key_st is > > opaque, so I can't ref it and then use that to copy the keyblock even. > > On May 8, 2015 8:41 AM, "Greg Hudson" wrote: > % (Don't use the _k variants; they use reference counts rather than > % copying, and krb5_keys are mutable and not internally locked..) > > > > In other words, I want to get the keyblocks with the current API, but > > then set the pointers without another call to krb5int_c_copy_keyblock. > > I guess I could make a couple new APIs since this is all linked > > statically in my app... > > See above. > > -Ben > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Does this separate thread connection need another as_req/rep pair?
On Sat, 13 Jun 2015, Chris Hecker wrote: > > Finally getting to this... > > > You might be able to make a new context and use > > krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(), > > krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to > > copy the keys. I don't think rd_priv and mk_priv use anything else in > > this configuration. > > I think I want the _k versions of the set functions, no? It looks like > the gets malloc a block, so the sets can just set and ref it, right? > Hmm, no, it looks like create_key also copies the data. Is there any > way to not do the wasted extra malloc? It looks like krb5_key_st is > opaque, so I can't ref it and then use that to copy the keyblock even. On May 8, 2015 8:41 AM, "Greg Hudson" wrote: % (Don't use the _k variants; they use reference counts rather than % copying, and krb5_keys are mutable and not internally locked..) > In other words, I want to get the keyblocks with the current API, but > then set the pointers without another call to krb5int_c_copy_keyblock. > I guess I could make a couple new APIs since this is all linked > statically in my app... See above. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Does this separate thread connection need another as_req/rep pair?
> Hm, you might be able to speed this up by supplying the service key > to the auth context with krb5_auth_con_setuseruserkey() Just to be clear, this would be they "key" member of the krb5_keytab_entry struct, right? I iterate the keytab already to get the princ, so I've got it sitting right there. I'm already using this API for u2u authn, it turns out (which is what it's for, I'm assuming :). 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
Re: Does this separate thread connection need another as_req/rep pair?
Finally getting to this... > You might be able to make a new context and use > krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(), > krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to > copy the keys. I don't think rd_priv and mk_priv use anything else in > this configuration. I think I want the _k versions of the set functions, no? It looks like the gets malloc a block, so the sets can just set and ref it, right? Hmm, no, it looks like create_key also copies the data. Is there any way to not do the wasted extra malloc? It looks like krb5_key_st is opaque, so I can't ref it and then use that to copy the keyblock even. In other words, I want to get the keyblocks with the current API, but then set the pointers without another call to krb5int_c_copy_keyblock. I guess I could make a couple new APIs since this is all linked statically in my app... Chris On 2015-05-08 08:41, Greg Hudson wrote: > On 05/08/2015 04:57 AM, Chris Hecker wrote: >> Hmm, thinking about this a bit more: if I turn off DO_SEQUENCE so I can >> share the auth_context, is there a way to dupe it so it can be used in >> both threads simultaneously? There shouldn't be any more mutable >> dependent state in there if there's no seq being used, right? > > You might be able to make a new context and use > krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(), > krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to copy > the keys. I don't think rd_priv and mk_priv use anything else in this > configuration. > > (Don't use the _k variants; they use reference counts rather than > copying, and krb5_keys are mutable and not internally locked..) > > Also, in addition to all of the attacks I mentioned for this auth > context configuration, reflection attacks are possible, where a message > from A to B is reflected back to A masquerading as a message from B. > You'll need to make sure to take that into account in your protocol, > perhaps just by making client-to-server messages look different from > server-to-client messages. > . > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Does this separate thread connection need another as_req/rep pair?
Yeah, my packet types are different for each direction. Out of curiosity, as discussed years ago, I also use "directional addressing" where I set a fake ip address for the local and remote that are the opposites for the two sides, so that would prevent reflections too, right? Chris On May 8, 2015 8:41 AM, "Greg Hudson" wrote: > On 05/08/2015 04:57 AM, Chris Hecker wrote: > > Hmm, thinking about this a bit more: if I turn off DO_SEQUENCE so I can > > share the auth_context, is there a way to dupe it so it can be used in > > both threads simultaneously? There shouldn't be any more mutable > > dependent state in there if there's no seq being used, right? > > You might be able to make a new context and use > krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(), > krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to copy > the keys. I don't think rd_priv and mk_priv use anything else in this > configuration. > > (Don't use the _k variants; they use reference counts rather than > copying, and krb5_keys are mutable and not internally locked..) > > Also, in addition to all of the attacks I mentioned for this auth > context configuration, reflection attacks are possible, where a message > from A to B is reflected back to A masquerading as a message from B. > You'll need to make sure to take that into account in your protocol, > perhaps just by making client-to-server messages look different from > server-to-client messages. > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Does this separate thread connection need another as_req/rep pair?
On 05/08/2015 04:57 AM, Chris Hecker wrote: > Hmm, thinking about this a bit more: if I turn off DO_SEQUENCE so I can > share the auth_context, is there a way to dupe it so it can be used in > both threads simultaneously? There shouldn't be any more mutable > dependent state in there if there's no seq being used, right? You might be able to make a new context and use krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(), krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to copy the keys. I don't think rd_priv and mk_priv use anything else in this configuration. (Don't use the _k variants; they use reference counts rather than copying, and krb5_keys are mutable and not internally locked..) Also, in addition to all of the attacks I mentioned for this auth context configuration, reflection attacks are possible, where a message from A to B is reflected back to A masquerading as a message from B. You'll need to make sure to take that into account in your protocol, perhaps just by making client-to-server messages look different from server-to-client messages. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Does this separate thread connection need another as_req/rep pair?
Hmm, thinking about this a bit more: if I turn off DO_SEQUENCE so I can share the auth_context, is there a way to dupe it so it can be used in both threads simultaneously? There shouldn't be any more mutable dependent state in there if there's no seq being used, right? Chris On May 7, 2015 2:22 PM, "Chris Hecker" wrote: > > 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
Re: Does this separate thread connection need another as_req/rep pair?
> 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
Re: Does this separate thread connection need another as_req/rep pair?
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
Re: Does this separate thread connection need another as_req/rep pair?
> 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. > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Does this separate thread connection need another as_req/rep pair?
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
Does this separate thread connection need another as_req/rep pair?
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. Now, I want the server to send the client info about another connection it needs to make back to the server on another thread. Does this connection need to do another AS_REQ/AS_REP exchange, or is there some cool way to take advantage of the original authentication on the first thread? Basically, in my tests I've found the initial AS_REQ authentication is pretty slow, so I end up timeslicing it when I've got lots of connections to the first thread, and I'd rather not have to take the time to do that again on the second thread if I don't need to. Sometimes the server will tell the client to connect to a completely different machine, so obviously in that case I need the full authn exchange (I assume), but in the case where it's a connection back to the same process, it'd be nice if there was some way to skip this step. 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. Am I missing something, or do I have to bite the bullet and do the full AS_REQ/AS_REP thing on the second connection? Let me know if that doesn't make sense. Thanks, Chris Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
