Documentation confusion on keytabs

[erinn]

What went wrong?

I think this is just a lack of understanding on my part, or a lack in the documentation, but I have been trying to understand how to specify a keytab to be used for the acquisition of the TGT. It appears you can use the KRB5_CLIENT_KTNAME environment variable, but this is undocumented (as far as I have found).

You have a mention of keytabs in the basic tutorial (which I really appreciate someone having written up by the way):

Note that for the krb5 mechanism, in order to acquire credentials with the GSSAPI, the system must already have a way to access those credentials. For users, this generally means that they have already performed a kinit (i.e. have cached a TGT), while for services (like above), having a keytab is sufficient. This process is generally performed outside the application using the GSSAPI.

But how do you specify the location? Is this part of the store variable: https://pythongssapi.github.io/python-gssapi/latest/gssapi.html#gssapi.creds.Credentials.store

I don't know, and I don't know how the dictionary for the store is supposed to look as there are no examples:

store (dict) – the store into which to store the credentials, or None for the default store.

Are we looking at something like this: https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html

Or am I totally missing the point?

[DirectXMan12]

So, it's not just you. This is a bit of a confusing question. The short answer, IIRC, is that there's no fully standard way to specify keytab location. The GSSAPI RFC itself (2743 and 2743) don't really "know" about keytabs, since they're mostly a krb-specific implementation detail, and you can have other GSSAPI implementations.

The KRB5_CLIENT_KTNAME is a krb5-specific mechanism, but will work. Later on, various implementations (namely, MIT krb5) added support for an unofficial extension for loading an storing from implementation-specific credential stores via the Credential Store Extension, not to be confused with RFC 5588, which looks suspiciously like the credential store extension, but exists to get your hopes up about a standard way to do this, only to dash them against the rocks of a significantly more specific use case.

So, the credentials store extension is mostly what you want. The problem is, the actual details of storing things are implementation-specific, which is why they're not really documented here (not so much as a matter of policy at this point, but that's a discussion we should have @frozencemetery). A MIT krb5-specific example can be found in the unit tests: https://github.com/pythongssapi/python-gssapi/blob/master/gssapi/tests/test_high_level.py#L189.

Unfortunately, IIRC, the full structure of that dict is only really documented in the krb5 code itself, but https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html shows part of the structure.

Please let me know if you have any more questions.

@frozencemetery we might want to have an "ancillary docs" section that documents quirks of MIT krb5, since most people are using this with that.

[frozencemetery]

Any docs around MIT-specific behavior we might want to run by MIT first in case they'd like to have them as well.

For the cred store case specifically, only MIT has implemented that to my knowledge. (I guess using $KRB5CCNAME works well enough for everyone else; per the krb5 project wiki, the cred store extension was developed for use in gssproxy.) A standardization attempt was begun but abandoned. In light of that, I'm comfortable documenting the MIT behavior as part of ours - any other implementation is unlikely to not comply.

[DirectXMan12]

@frozencemetery careful with those wiki pages. They're often subtly broken or out of date, in my experience (or were when I started writing python-gssapi).

[frozencemetery]

I mean, sure? I'm just citing the "Background" section here, and it also had the kitten link which was helpful. there isn't really anything else in it.

[erinn]

So, any chance one of y'all could document this?

[DirectXMan12]

I think it just ended up being a matter of time (namely, we all ran out of it). At this point, I'd gladly accept external contributions, but I don't know if I'll have time soon to get back to this. Perhaps @frozencemetery can weigh in?

[erinn]

I can't help here sorry. This one needs people who are very familiar with how things work to write it out so others like myself have a fighting chance of understanding what is going on and how to implement it. The best I could possibly do would be a wild guess that might do more harm than good.

[frozencemetery]

If memory serves, this should be covered by credstore.rst.

[L0ckR]

So, the credentials store extension is mostly what you want. The problem is, the actual details of storing things are implementation-specific, which is why they're not really documented here (not so much as a matter of policy at this point, but that's a discussion we should have @frozencemetery). A MIT krb5-specific example can be found in the unit tests: https://github.com/pythongssapi/python-gssapi/blob/master/gssapi/tests/test_high_level.py#L189.

Hello

i got error trying to recreate part of this unit test
MissingCredentialsError: Major (458752): No credentials were supplied, or the credentials were unavailable or inaccessible, Minor (2529639053): Can't find client principal XXX@XXXX in cache collection

Why do i need to have ccache with credentials, if i want to use keytab for init creds
Is there some example of using keytab username and keytab for initializing kerberos credentials