Thanks a lot for all the answers! > copies objects by pointer), but I'd consider use cases for this one > since we have historical APIs which use caller-allocated krb5_data > containers.
Yeah, they've very common in the samples, as well. Chris On 2011/09/28 08:11, Greg Hudson wrote: > On Tue, 2011-09-27 at 01:42 -0400, Chris Hecker wrote: >> 1. What's the difference, if any, between get_credentials with the >> CACHED flag and cc_retrieve_creds? > > The difference is minimal, other than details like the meaning of flags. > >> 2. I talk to the KDC in a dedicated thread, which has its own >> krb5_context. Is it okay to use the krb5_creds allocated on that >> context with the main thread's context? If not, do I need to do the KDC >> communication on its own thread, then use the ccache for moving the >> creds to the main thread? > > krb5 objects are never restricted to the context they were created in. > The only restriction is that some objects (most notably krb5_context) > may only be used in one thread at a time. (krb5_creds is, I think, not > modified after creation by any APIs, so isn't in that class.) > >> 3. mk_req takes a krb5_data and will make a checksum from it, but I >> don't see any way to use that on the rd_req side? Am I missing >> something, or is this just some internal thing? Or is it the checksum >> in the authenticator you can get through krb5_auth_con_geauthenticator? > > I believe krb5_auth_con_getauthenticator is how you'd get at the > checksum on the receiver side, yes. > >> 4. Is there a way from an existing in-use auth_con to get the client >> and server princs? > > That information doesn't appear to be stored in the auth context (well, > the client princ is stored via the authenticator). > >> 5. Does mk_priv also checksum the data, in addition to encrypting it? > > Yes. RFC 3961 cryptosystems include integrity protection. (The > exception is the raw enctypes for DES and DES3, which are only intended > for internal use by the GSSAPI code.) > >> 6. Do I need to rd_priv/safe every mk_priv/safe packet I get to keep >> the sequence numbers correct (DO_SEQUENCE is on the auth_con), or can I >> skip some? > > You can't skip any. > >> 7. Why is krb5int_copy_data_contents krb5int? > > I could make guesses as to why it was added that way but they'd be > speculation. From my point of view, in theory I don't want a lot of > _contents APIs (code is cleaner and more robust when it constructs and > copies objects by pointer), but I'd consider use cases for this one > since we have historical APIs which use caller-allocated krb5_data > containers. > >> 8. For u2u authn, I think the user_user sample is backwards. In other >> words, it's always the client in a normal krb5 application that calls >> get_credentials and talks to the KDC, yet in the user_user sample that >> code is in server.c. > > Again, I could only really speculate as to why it's organized that way. > But even if you reversed the roles, the server would still have to > maintain a TGT which means talking to the KDC (although that could be > done by a separate process). > > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
