a bunch of random krb5 questions

[Chris Hecker]

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