compile krb5-1.13.2 with a static openssl lib on linux
Hi, I need to build KDC with a static openssl lib. How to compile KDC that uses a static openssl lib? Thanks Jim Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: returning krb5_rd_req error code to clients
On 06/13/2015 07:38 AM, Chris Hecker wrote: Is it a problem to return the krb5_rd_req error code on failed authn to clients? Is that revealing information it shouldn't and I should just return success or failure? Or filter it down to a few safe ones, like clock skew, etc? The error code might reveal a little information, but not much. Do note that the code might be a system errno value, and those aren't portable across operating systems. The extended error string can reveal more information, particularly in 1.13; for instance, it can say Request ticket server %s kvno %d found in keytab but not with enctype %s. I don't think we're currently including the pathname to the keytab, but it might be there in the future. In general, we wouldn't include information in a server-side error message which would immediately allow an attack (like keytab key hex cannot decrypt ticket), but we might include information which could conceivably assist in targeting an attack. It's really an administrative decision whether to keep information like that private in the server logs, or send it to the client in order to more easily resolve problems. 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
returning krb5_rd_req error code to clients
Is it a problem to return the krb5_rd_req error code on failed authn to clients? Is that revealing information it shouldn't and I should just return success or failure? Or filter it down to a few safe ones, like clock skew, etc? Chris 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
