Authentication Indicators and Cross Realm Trust

[Simo Sorce]

On Sun, 2022-10-09 at 17:38 -0400, Ken Hornstein via Kerberos wrote:
> > On 9/30/22 16:06, Machin, Glenn Douglas via Kerberos wrote:
> > > Can someone tell me if a TGT containing an authentication
> > > indicator will work over to a service principal in another realm
> > > which has a cross realm trust relationship?
> > 
> > Authentication indicators are currently only accepted within the
> > same 
> > realm; cross-realm service ticket requests do not preserve the 
> > indicators from the cross-realm TGT.
> 
> Hm, should they be preserved?

When we produced the RFC we made them inherently local for two reasons:
- no consensus on actual identifiers
- there is no guarantee that the policy on what to consider
valid/sufficient 2FA is the same between different domains.

> We are in the unusual situation of (a) relying on ticket flags to
> indicate the use of hardware preauth and (b) we do a lot of cross-
> realm.  So we depend on the client realm asserting the hw-auth ticket
> flag and make authorization decisions based on that (obviously, we
> trust those realms to only assert hw-auth flag when appropriate). 
> AND my eventual plan was to transition to authentication indicators
> instead of the hw-auth ticket flag.

This indicates you have a trust relationship but a single policy
domain. It would be nice to have some KDC option that would allow to
trust (and transport) indicators from one real to another for these
cases. You can technically do it with a KDC plugin (which could also
then translate indicators if the two realms use different definitions,
but may make sense to have a feature to just carry them forward for
specific realm-to-realm relationships.

> RFC 8129 acknowledges the existence of cross-realm authentication and
> vaguely implies they will be preserved, specifically here:
> 
>    Application service evaluation of site-defined indicators MUST
>    consider the realm of original authentication in order to avoid
>    cross-realm indicator collisions.  Failure to enforce this
> property
>    can result in invalid authorization decisions.

Correct, the spec thought about this case, but didn't give any guidance
becaue there was no consensus/though on how indicators can work cross-
realm (outside of a same policy domain of operation).

> So is this just an implementation detail?  Is there something more
> that I am missing? (Entirely possible!).

You can consider this just an implementation detail, I think.

> If it's just an implementation detail, what would the parameters of
> an acceptable patch look like?

I think it would be an option that specifies explicit realms from which
to accept indicators as "trusted" and then ok to copy on.

>   E.g., would the default be to not accept
> any authentication indicators when doing cross realm, and you have to
> explicitly list realms you accept authentication indicators from?

I think  this would necessarily need to be the way to go.

> Or something else?

You could also write a KDB plugin that could do more interesting things
like mapping indicators from one realm to another, but I think we could
have a default way to handle this for the simplest case where both
realms are really handle by the same organization and are "fully
trusted" to relay this information from one to another.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc