Mailing list discussion follows:

We have previously discussed the need for IPA httpd to access both
dogtag/ and HTTP/ keys. You advised that due to the design
of gssproxy or underlying libs, all the keys for the different
principals have to reside in a single keytab file. This leads to
another problem.

Assume all the required keys are in http.keytab. The user
apache has access to all the keys it needs (good). But other
users that gssproxy allows to use that keytab have access to keys
that perhaps they should not have. e.g. [service/ipa-api] could
initiate as the dogtag/ principal. This is undesirable.

Similarly, in my GSS-API work pkiuser will need access to
dogtag/, but it shouldn't be allowed to use the HTTP/ keys
too.

So, how do we solve this? I see two ways:

1. add a gssproxy configuration directive to say which principals in
   the keytab the euid is allowed to use. Config might look like:

   [service/ipa-api]
   mechs = krb5
   cred_store = keytab:/var/lib/ipa/gssproxy/http.keytab
   cred_store = client_keytab:/var/lib/ipa/gssproxy/http.keytab
   allow_constrained_delegation = true
   cred_usage = initiate
   euid = ipaapi
   valid_names = HTTP/hostname REALM # restrict to HTTP/ principal

-or-

1. use ktutil to merge/split keytabs as appropriate. This feels
   quite hackish both in implementation (manual incantations of
   ktutil(1)) and outcome (some kerberos keys may exist in multiple
   keytabs; more work to do when rotating keys, etc). But it does
   not require any changes to gssproxy.

My preference is for (1). What do you think of the idea? Do you
have better idea(s)?

The ipa-pki GSS-API work has been deferred post-7.4 so there is no
rush. I am happy to tackle the work in gssproxy if you think it's a
good approach.

We already have the krb5_principal option to suggest what principal can
be used, but it does not enforce it indeed. However I am wondering if it
would really be an issue for you if someone can kinit with the dogtag
principal, what attack scenario do you see ?

That said, because in AD environment all keys are shared by the same
host, I am thinking an option to restrict the allowed service name is
probably not a bad idea, please open an issue in pagure so we don't
forget.