# Policies by authentication indicators

## Overview

Based on the pre-authentication mechanism a user used to acquire the credential, 
the KDC can enforce policies such as service access control, 
user authentication and ticket lifetime/reissue time policies to achieve a finer control over ticket issuance.

## Authentication indicators

Authentication indicators are attached by KDC to tickets issued to user and depend on 
which pre-authentication mechanism used to acquire the credential. 
Indicators and corresponding mechanisms are listed below:

| Authentication indicator | Mechanism            |
|:------------------------ | :------------------- |
| radius                   | RADIUS               |
| otp                      | Two factor authentication (password + OTP) |
| pkinit                   | PKINIT               |
| hardened                 | Hardened Password (by SPAKE or FAST) |
| idp                      | External Identity Provider |

Hardened password means a password authentication with either SPAKE or FAST armoring enabled. 
Although it is possible to assign separate indicators to SPAKE and FAST, when both SPAKE and FAST are used, 
only the indicator for SPAKE will be applied. 
Since there is no practical reason to forbid the use of SPAKE while using FAST armoring, 
these two are assigned the same indicator to represent a brute-force hardened form of password authentication.

By requiring certain authentication indicators to a user, we can force a user to be authenticated with one of 
the mechanisms associated with those auth indicators to obtain a ticket.
By defining an allow list of authentication indicators to a service, we can allow a user to use the service
only if the user obtained a ticket with at least one of those indicators included.

### Note

For unattended services (services that is a part of the IPA core system), the authentication indicator should not be set, 
or it may break the whole system. Examples for such services are `HTTP/*` (for webUI and IPA API end-points), 
`ldap/*` (for user data management etc.), `cifs/*` (for SMB and DCE-RPC services), 
also for `host/*` on IPA masters which are used by DCE-RPC services to validate client-server communication.

## Available policies and user interface

### Connection policy

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`

Services with no authentication indicator assigned will accept tickets authenticated by any mechanism.

#### CLI Workflow:

Administrators can specify required auth indicators for a service via `ipa service-mod` command.

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.

### Ticket lifecycle policy

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

Tickets without an authentication indicator will have the default lifetime / renewtime.

#### 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 --otp-maxlife=604800 --pkinit-maxlife=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: 86400
OTP max life: 604800
PKINIT max life: 604800
Max renew: 604800
```

#### WebUI Workflow:

In Policy/Kerberos Ticket Policy tab, there is a table 
where administrators can specify max renew and life for each supported auth indicator.

### Ticket lifetime jitter

All TGT lifetimes are varied slightly to avoid overwhelming the KDC with
simultaneous renewal requests.  Jitter will reduce lifetimes by up to one hour
from the configured maximum lifetime (per policy).  Significantly shorter
requested lifetimes will be unaffected.

## Implementation

Kerberos policy, as krb5 presents it, consists of two interfaces: 
the authentication indicator attributes and the kdcpolicy plugin.
Authentication indicator attributes allow us to make boolean access choices
(i.e. allow or deny service principal requests) on the KDC based on configuration in the Kerberos Database (KDB).
The kdcpolicy plugin is a much more powerful hook, allowing refinement of the request itself rather than 
a solely boolean decision.

Connection Policy can be implemented with authentication indicator attribute in krb5 alone, 
but ticket lifecycle policy will require LDAP to store relations between authentication indicators
and lifetime information. We have global ticket lifetime and renew time setting stored as attribute 
`krbmaxticketlife` and `krbmaxrenewableage` inside the `cn=$REALM,cn=kerberos,$SUFFIX` subtree, 
which represents the default lifetime policy.

Two new multi-valued attributes are added to store an authentication
indicator-specific maximum ticket life and ticket's maximum renewable age. The
type of authentication indicator is specified as LDAP attribute option:

```
krbAuthIndMaxTicketLife;otp: 604800
krbAuthIndMaxRenewableAge;pkinit: 604800
```

They are stored in the same policy object in LDAP.