#8010 Extended Kerberos Ticket Policy
Opened a month ago by tengcm. Modified a month ago

By utilizing authentication indicator and kdcpolicy plugin in kerberos, we can implement some new ticket issuance policies to extend the capability of freeipa.

1. Connection policy by auth indicator

Different service may need different security strength and consequently requires different pre-auth mechanism.
e.g. must have used 2FA or OTP in order to connect to host/securemachine@REALM

CLI Workflow

Administrators can specify required auth indicators for a service via ipa service-mod command (already implemented)
e.g. ipa service-mod service/@REALM --auth-ind otp --auth-ind pkinit

WebUI Workflow

Administrators can specify required auth indicator on service settings page. As default no auth indicator is specified which means all pre-auth mechanism is accepted.

Note

This feature is implemented as in this PR. However, it leads to changes in IPA server API. Further analysis needed for compatibility problems.
See also: #8001

2. Ticket lifecycle policy by auth indicator

Administrators may want to define different ticket expiration and renewal values as well as ticket flags based on the type of the authentication conducted.
e.g. the lifetime of the OTP based ticket can be longer than for a single-factor

CLI Workflow

Administrators can specify max life and renew for each auth indicator and global default via ipa krbtpolicy-mod command.
e.g. ipa krbtpolicy-mod --setattr maxlife=[{"default":"86400","otp":"604800"}]

Current --maxlife and --maxrenew options for ipa krbtpolicy-mod will set the default max life / renew respectively.

After this, the output for ipa krbtpolicy-show will look like:

  Max life:
  - default: 86400
  - otp: 604800
  Max renew:
  - default: 604800

WebUI Workflow

There will be a new table in Policy/Kerberos Ticket Policy tab where administrators can specify Max renew and life for each auth indicator. Custom indicators can be added in case it is specified in some of the services.

3. Ticket lifetime jitter

Ticket lifetimes can be jittered so that renewals / re-issues do not overwhelm the KDC at a certain moment.

Our design choice is to keep this feature enabled constantly and don’t expose any interface for toggling. This way we can avoid triggering an LDAP query on every AS_REQ and TGS_REQ.

There is also a possibility to enable jittering partially by default.
e.g. Enable for TGS_REQ only
e.g. Enable for tickets of hostbased services only

Note

An alternative design is to make this feature toggle-able. Weather this design is applied or not depends on if there are good reasons to keep max life / renew exactly as in the original requests, and if those reasons justifies the LDAP query overhead.

CLI Workflow

Administrators can specify if max life and renew is jittered or not via ipa krbtpolicy-mod command.
e.g. ipa krbtpolicy-mod --setattr maxlife-jitter=true

WebUI Workflow

Administrators can enable/disable this feature in Policy/Kerberos Ticket Policy tab.

Documentation Considerations

Authentication indicator and kdcpolicy documentation already exists within krb5. However, IPA will need its own documentation when merging features.


(While this is technically an RFE, @tengcm is committed to doing this work under our supervision.)

Thanks for the proposal.

Those three use cases are valid ones and can be implemented.

I've started looking at the possible policies and what users have requested in past and I think that a current mechanism combination is not enough for multiple practical use cases. In most of these cases we have to deal with a combination of methods at an application layer, not purely on KDC side.

One of the most requested features is to allow sudo operations single sign-on after user did login with a particular authentication indicator set on their TGT. I.e. you'd login using smart card authentication (gaining 'pkinit' authentication indicator on your TGT). A subsequent use of sudo should not require a password if your TGT has 'pkinit' authenticator. This request comes from multiple customers and is relevant to environments where use of a bare password is prohibited for users. Same should be possible for 'otp' authentication indicator.

The problem here is that sudo use is outside of Kerberos flow. On IPA client, sudo operation will try to use PAM stack to authenticate and authorize user access to sudo service before authorizing actual sudo rules usage. Authorization here means validation of HBAC rules associated with an HBAC service named after the PAM service (e.g. sudo or sudo-l for various sudo access patterns). Authentication here effectively means obtaining a new Kerberos TGT by SSSD (in PAM stack) which means we are performing again the original smart-card or OTP token authentication sequence. If SSSD would learn to be able to reuse a TGT from an initiating user's credentials cache, it still would be good to request a service ticket to some Kerberos service to validate that such access can be granted based on Kerberos ticket properties. The problem is that we don't have such service other than the original host/client one. If the original one is only allowed to use a particular authentication indicator, we would not be able to differentiate access to separate services on the same host.

Right now there is no support for a 'sub-service' Kerberos service in IPA that could have different authentication indicators associated to allow per-service differentiation for HBAC services.

Technically, we could add an SPN-like service and teach SSSD to request a ticket to it. SPN name format is <service class>/<host>[:<port>]/<service name>. On Windows, SPNs are aliases to existing machine account of the host they are placed on. In FreeIPA, we could already add aliases to host and service principals:

# ipa host-add-principal `hostname`  host/`hostname`/sudo
-------------------------------------------
Added new aliases to host "host.example.com"
-------------------------------------------
  Host name: host.example.com
  Principal alias: host/host.example.com@EXAMPLE.COM, host/host.example.com/sudo@EXAMPLE.COM

However, such alias will not be able to differentiate authentication indicators per service as it would be indistinguishable from the original primary Kerberos service name (host/host.example.com@EXAMPLE.COM in this case). Aliases have no own properties right now.

Theoretically, KDC policy plugin could look at such case, recognize an HBAC service in the target service principal and then look up required authentication indicators from an HBAC service. But this is not possible because KDC implementation of both AS and TGS request processing does validate authentication indicators before calling to a KDC policy plugin. The plugin calls do get access to a list of indicators associated with a ticket to be issued but they cannot affect what indicators were acceptable by the service to issue a ticket to. It means such replacement of the accepted authentication indicators would need to be done when fetching the target principal from the database before authentication indicators were to check.

Theoretically, KDC policy plugin could look at such case, recognize an HBAC service in the target service principal and then look up required authentication indicators from an HBAC service. But this is not possible because KDC implementation of both AS and TGS request processing does validate authentication indicators before calling to a KDC policy plugin. The plugin calls do get access to a list of indicators associated with a ticket to be issued but they cannot affect what indicators were acceptable by the service to issue a ticket to. It means such replacement of the accepted authentication indicators would need to be done when fetching the target principal from the database before authentication indicators were to check.

@abbra I'm not sure I totally understand what you're saying here. Permitted authenticators for a service is under IPA control already; why do you need it to be dynamic at AS/TGS request time? (Ignoring for a moment that this is untenable for performance reasons.) If you have a separate "PKINIT sudo" service, why wouldn't you just set it to always need PKINIT?

Because right now there is no such thing as per-PAM service Kerberos service. There is always a single host/... Kerberos service that is used by SSSD when validating a user ticket. It means we cannot have a system where users can login with a smartcard but don't get asked for a password auth anymore over sudo. There is no way to distinguish the services at all.

If we were to introduce per-PAM service Kerberos service, there is probably an overhead of having whole service object, though. Having it as an alias to a host service would be enough, key-wise. All we need is to be able to differentiate per SPN what auth indicators apply. We can store those somewhere else, coupled with HBAC rules objects, for example.

It's not a lot of overhead from the krb5 side - does something make it difficult for IPA?

Creating per-PAM service Kerberos services would mean a lot of keys that aren't really used for anything other than Kerberos ticket validation through SSSD. Technically, it also means that SSSD would need to obtain these keys on each host and maintain keytabs collections. Now, this part becomes harder: not only SSSD has no way to operate on keytab collections, it is not really needed as nothing but SSSD itself would be obtaining TGT to the service in question, only to validate that KDC did indeed issued a ticket on SSSD request itself.

So it is less practical than to add Kerberos principal alias and make a lightweight object associated with the alias to store auth indicator and other details but not the keys themselves.

Alright. So backing up a bit, when we've discussed Kerberized sudo in the past, auth indicators were not in play. The kdcpolicy plugin interface was built in part to enable that use case - a requirement which later disappeared. However, we see it as a useful tool for other things as well, which is what we're focusing on here.

Kerberized sudo was dropped from the roadmap because it was unclear what additional guarantees it provided over NOPASSWD/!authenticate (see here). The design at the time was a sudo/hostname service principal to which we could issue tickets with very short lifetimes. It would have required additional work outside of krb5/IPA to complete this design (including a PAM module), but the kdcpolicy plugin as it stands suffices to implement this design.

Thanks, Robbie.

I think one issue with NOPASSWD/!authenticate for the environments we are discussing is that it doesn't take into account the concept of elevated security. It doesn't allow to get authentication step removed for cases when smartcard authentication was used to obtain original Kerberos ticket. NOPASSWD is all or nothing, it takes no differentiation on the environment state. So far, we have no way to apply this differentiation.

Getting back to the original proposal, I would like to understand what in the first use case means the statement about step-up exclusion. In general, it would be nice to expand on the actual use case flow -- what is expected to happen?

The problem I see with existing pull request is that it is basically ignores two out of three parts it needs to update. IPA framework metadata on the server side defines what clients might pass in and if StrEnum class has no particular value, the value sent by the client will be rejected. Another part is KDB driver -- it has hardcoded values supported for auth indicator in a Kerberos service/user entry. Without a clearly defined logic for additional values, there is no understanding how the code should behave in KDB for the additional indicators.

Certauth plugin forces 'pkinit' indicator -- while it could be redefined in kdc.conf, it is hardcoded in ipa_certauth_authorize(). Same for otp and radius indicators in ipadb_parse_ldap_entry().
I'm trying to understand how would additional types of indicators fit there but there is not enough information in the proposed PR or here.

I think the line about step-up is a copy-paste error; @tengcm, could you please remove it (unless I've missed something)? I'd do it myself but I can't edit it.

As for the rest: I'm not sure what to tell you? I think it makes sense to require that the auth indicators follow a specific hardcoded string - we already don't support hand modifications to kdc.conf. But I'm not sure if that's even what you're talking about here. If you're asking what should be done for unrecognized auth indicators, ignoring them is the correct thing to do. The ticket is valid and authorized, just not in a way you can add special handling to.

I think the line about step-up is a copy-paste error

@rharwood Removed.

Login to comment on this ticket.

Metadata