Re: user2user GSSAPI [was Re: threading best practices?]
I'd like the mech to work for u2u. I've a proposal: - If the initiator knows it wants user-2user then let it send a bogus AP-REQ (a constant one, actually) with a new APOptions flag that denotes I want to do user2user, so gimme a TGT. If the acceptor doesn't support this then it will respond with a KRB-ERROR, else with a Ticket, in which case there's one more round-trip: the AP-REQ with the user2user Ticket that the initiator is then able to get. (Aliasing should be handled in the TGS exchange, with the KDC validating that the 2nd ticket corresponds to the name that the initiator wanted for the target principal. Note that this would allow us to have targets where the initiator doesn't know their name a priori, something Martin's been wanting for a long time :) - If the initiator had a valid service ticket but the acceptor wanted to do user2user (this is not likely, but hey), then we need a flag in the AP-REQ (probably an APOption flag, maybe the same as above, and possibly an authz-data element for the Authenticator) by which the initiator can indicate its willingness to go on for an additional round-trip, in which case the acceptor's KRB-ERROR will indicate that it wants user2user auth and the e-data will bear the acceptor's TGT. In the first case there's the issue of what happens if the acceptor doesn't support the new thing: failure. So you'd have to upgrade the acceptor, but you were going to have to install new software if you went with the raw krb5 API anyways... In the second case there's the issue of what happens if the initiator doesn't support the new thing: failure, but we don't care because the second scenario shouldn't happen anyways (unless I'm missing something). Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
On 23/07/2011, at 12:22 AM, Nico Williams wrote: On Fri, Jul 22, 2011 at 7:04 PM, Greg Hudson ghud...@mit.edu wrote: On Fri, 2011-07-22 at 18:10 -0400, Nico Williams wrote: Why are you not using the GSS-API? Chris started out by asking about user-to-user auth, so I didn't redirect him to GSSAPI since, as far as I know, GSSAPI doesn't have a story there (for the krb5 mech, at least). Indeed, the krb5 mech has no story here. I'm thinking we should have the initiator send a bogus AP-REQ with a new auth-options flag. If the server understands it it would respond with a KRB-ERROR with the TGT in the e-data, else with a plain KRB-ERROR. Hasn't draft-swift-win2k-krb-user2user-03 been shipping since Windows 2000? -- Luke Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
On Fri, Jul 22, 2011 at 12:03 AM, Chris Hecker chec...@d6.com wrote: I don't think any u2u stuff is stored in a krb5_context. Can you be more specific about what you're seeing here? I'm not seeing anything yet, since I'm still trying to figure out how I'm going to do this by playing around with the sample apps. I think I'm getting confused between krb5_context and krb5_auth_context, I'm not totally clear on how they relate or depend on one another... krb5_context is just a caller context that must be passed to practically all krb5 APIs. krb5_auth_context is the raw krb5 API equivalent of GSS' gss_sec_context_t -- it represents an authenticated channel between two end-points. Okay, so if I krb5_get_credentials on the KDC thread, I can then use them in the main thread with a different context... Yes, pretty much. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
Okay, so if I krb5_get_credentials on the KDC thread, I can then use them in the main thread with a different context... Yes, pretty much. So, I should create the auth_context in the thread that's doing the actual communication with each other machine, right? There seem to be some calls to DNS in various functions, so I'm going to need to be careful to make sure everything's cached in the KDC thread so nothing blocks on the other threads... I'm building a test program so I can figure out exactly what needs to be where for my use-case. I assume I can have multiple auth_contexts in a single thread, as long as I keep straight which one is talking to which other client or server and pass them to mk_safe/mk_priv appropriately... Thanks, Chris On 2011/07/22 12:51, Nico Williams wrote: On Fri, Jul 22, 2011 at 12:03 AM, Chris Heckerchec...@d6.com wrote: I don't think any u2u stuff is stored in a krb5_context. Can you be more specific about what you're seeing here? I'm not seeing anything yet, since I'm still trying to figure out how I'm going to do this by playing around with the sample apps. I think I'm getting confused between krb5_context and krb5_auth_context, I'm not totally clear on how they relate or depend on one another... krb5_context is just a caller context that must be passed to practically all krb5 APIs. krb5_auth_context is the raw krb5 API equivalent of GSS' gss_sec_context_t -- it represents an authenticated channel between two end-points. Okay, so if I krb5_get_credentials on the KDC thread, I can then use them in the main thread with a different context... Yes, pretty much. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
On Fri, Jul 22, 2011 at 4:46 PM, Chris Hecker chec...@d6.com wrote: Okay, so if I krb5_get_credentials on the KDC thread, I can then use them in the main thread with a different context... Yes, pretty much. So, I should create the auth_context in the thread that's doing the actual communication with each other machine, right? There seem to be Yes, but that's not a requirement. some calls to DNS in various functions, so I'm going to need to be careful to make sure everything's cached in the KDC thread so nothing blocks on the other threads... krb5_mk_req*() should not require any DNS lookups. krb5_sname_to_principal() can do blocking network I/O for principal canonicalization (let's not get started on that) and krb5_get_credentials() can do blocking network I/O (TGS exchange(s) to get the desired service ticket). Why are you not using the GSS-API? I'm building a test program so I can figure out exactly what needs to be where for my use-case. Great! I assume I can have multiple auth_contexts in a single thread, as long as I keep straight which one is talking to which other client or server and pass them to mk_safe/mk_priv appropriately... Right. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
On Fri, Jul 22, 2011 at 7:04 PM, Greg Hudson ghud...@mit.edu wrote: On Fri, 2011-07-22 at 18:10 -0400, Nico Williams wrote: Why are you not using the GSS-API? Chris started out by asking about user-to-user auth, so I didn't redirect him to GSSAPI since, as far as I know, GSSAPI doesn't have a story there (for the krb5 mech, at least). Indeed, the krb5 mech has no story here. I'm thinking we should have the initiator send a bogus AP-REQ with a new auth-options flag. If the server understands it it would respond with a KRB-ERROR with the TGT in the e-data, else with a plain KRB-ERROR. It'd be nice to also make KRB_AP_ERR_USER_TO_USER_REQUIRED a retriable error, with the TGT in e-data. Again, a new auth-options flag would help here. (But this error is not likely to be very common at all. Instead I imagine that clients will get KDC_ERR_MUST_USE_USER2USER and so they'll just know to ask for a u2u TGT.) Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
Chris is also pretty allergic to layers and indirection in his software unless they're absolutely necessary, so he's quite happy that he can talk directly to kerberos, since he's not going to swap out the security layer or anything, so GSSAPI would just be adding overhead (conceptual, if not computational) for me. Chris On 2011/07/22 17:04, Greg Hudson wrote: On Fri, 2011-07-22 at 18:10 -0400, Nico Williams wrote: Why are you not using the GSS-API? Chris started out by asking about user-to-user auth, so I didn't redirect him to GSSAPI since, as far as I know, GSSAPI doesn't have a story there (for the krb5 mech, at least). Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
krb5_mk_req*() should not require any DNS lookups. krb5_sname_to_principal() can do blocking network I/O for principal canonicalization (let's not get started on that) and krb5_get_credentials() can do blocking network I/O (TGS exchange(s) to get the desired service ticket). Cool, thanks for the pointers. I'll keep track of any issues I run into and document them on the wiki or something. I'm building a test program so I can figure out exactly what needs to be where for my use-case. Great! I'd be happy to contribute it back, but sadly I'm not sure how to do the threading stuff in a cross platform way. Speaking of which, I've ported some of the samples to work on Win32, I'll try to clean those up and contribute them back. I may also try to get kadmin running on Win32 at some point, since it looks like a bunch of people have asked about it in the past, and it would be handy for me to have. Chris On 2011/07/22 15:10, Nico Williams wrote: On Fri, Jul 22, 2011 at 4:46 PM, Chris Heckerchec...@d6.com wrote: Okay, so if I krb5_get_credentials on the KDC thread, I can then use them in the main thread with a different context... Yes, pretty much. So, I should create the auth_context in the thread that's doing the actual communication with each other machine, right? There seem to be Yes, but that's not a requirement. some calls to DNS in various functions, so I'm going to need to be careful to make sure everything's cached in the KDC thread so nothing blocks on the other threads... krb5_mk_req*() should not require any DNS lookups. krb5_sname_to_principal() can do blocking network I/O for principal canonicalization (let's not get started on that) and krb5_get_credentials() can do blocking network I/O (TGS exchange(s) to get the desired service ticket). Why are you not using the GSS-API? I'm building a test program so I can figure out exactly what needs to be where for my use-case. Great! I assume I can have multiple auth_contexts in a single thread, as long as I keep straight which one is talking to which other client or server and pass them to mk_safe/mk_priv appropriately... Right. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
On Fri, Jul 22, 2011 at 8:04 PM, Chris Hecker chec...@d6.com wrote: Chris is also pretty allergic to layers and indirection in his software unless they're absolutely necessary, so he's quite happy that he can talk directly to kerberos, since he's not going to swap out the security layer or anything, so GSSAPI would just be adding overhead (conceptual, if not computational) for me. If you need the mechanism to be Kerberos and know you'll never want a different mechanism in your app, then using the krb5 API directly is fine. GSS doesn't add that much more layering, and the layering it does add adds value, IMO. As for conceptual overhead, the GSS-API is simpler than the MIT krb5 API :) Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: threading best practices?
On Thu, 2011-07-21 at 23:01 -0400, Chris Hecker wrote: I need to do normal client-server authn and also client-client authn, which I'm going to do with the user-to-user stuff, so I'll need to talk to the KDC multiple times per session. It seems like the u2u stuff is stored in the context, so I'm not sure how to make all this work. I don't think any u2u stuff is stored in a krb5_context. Can you be more specific about what you're seeing here? In general, you should be able to have a separate krb5_context in each thread, and just configure them all the same way (if you need to configure them at all). Objects like credentials and ccaches can be obtained with one library context and used in another. You need to know what is internally locked (or internally immutable) and what is not to know when the same object can be used in multiple threads simultaneously, which is unfortunately underdocumented. I'd also like to guarantee nobody in krb5 will try to use a socket without me specifically asking them to, so is there a list of APIs that talk to the net? An example is some APIs have a flag that tells them to fail with an error code instead of contact the KDC, which is what I want. Can anybody think of APIs I need to watch out for here? I'm not sure there is such a list. We've added a lot of API documentation in the form of Doxygen comments on the trunk for the 1.10 release, which may help. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
