#166 Add option to restrict what principal(s) can be used
Closed: Deferred 3 months ago by simo. Opened 3 years ago by ftweedal.

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

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:

    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


  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

Project has moved please reopen here if still an issue:

Metadata Update from @simo:
- Issue close_status updated to: Deferred
- Issue status updated to: Closed (was: Open)

3 months ago

Login to comment on this ticket.