a bunch of random krb5 questions

[Greg Hudson]

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).