Keytab-based initiator creds design

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:


    Greg> On another note, I'm not sure it makes sense to implement any part of
    Greg> keytab initiation in krb5_get_credentials/krb5_tkt_creds_* (as opposed
    Greg> to just in the gss-krb5 mech).  krb5_get_credentials doesn't use the
    Greg> default ccache, so it doesn't really make sense for it to use the
    Greg> default client keytab.  Also, doing it in krb5_get_credentials
    Greg> wouldn't actually help for FAST armor ccaches (since the FAST code
    Greg> just uses krb5_cc_*), so I'm not sure there are any use cases more
    Greg> interesting than krlogin.


I'd like to take a look at doing this for fast armor  (no promise
on timing) and I guess there is an interesting discussion of where the
credential gets stored that needs to be resolved.
So, it would be desirable if your implementation thought about potential
code reuse from within the krb5 library.
However I agree that doing this in krb5_get_credentials doesn't make
sense.