Using authentication indicators

[Greg Hudson]

On 3/30/23 16:01, Ken Hornstein via krbdev wrote:
> - There does not seem to be a public krb5 API to decode authentication
>    indicators.
[...]
>    Also, I'm a little unclear on how the authdata_context has access to
>    the authentication indicators from the AP-REQ!

krb5_rd_req_dec() initializes an authdata context and runs the authdata 
modules over the ticket authdata.  (The authdata pluggable interface 
isn't public and hasn't been converted to the new plugin 
infrastructure.)  One of those modules (authind) extracts authentication 
indicators.  The resulting authdata context is stored in the 
krb5_auth_context.  The krb5 gss_accept_sec_context() fetches this 
authdata context from the auth context and copies it into the src_name 
output so that the GSS naming extensions can fetch values from it.  None 
of the libkrb5 interfaces used for this are public.

I think the conservative option here would be to provide public APIs 
corresponding to krb5_authdata_get_attribute() and 
krb5_authdata_get_attribute_types() but which operate on auth contexts. 
Another option is to make the krb5_authdata_context type and functions 
public, but that's a lot of new API surface.

> - As previously discussed, authentication indicators are not passed
>    through when using cross-realm authentication, and that's an issue
>    for us as we make use of cross-realm authentication (ticket flags
>    ARE passed through cross-realm, but I realize when that decision
>    was made it was a simpler time).

We could start with a string attribute on the incoming cross-tgt entry 
that permits some or all auth indicators to be propagated as-is.  Off 
the cuff I'd imagine an attribute named allow_indicators, where the 
value "*" means any indicator and otherwise it's a space-separated list 
of indicators.

More generalized cross-realm support would allow a plugin module 
(perhaps the KDB module, or a KDC policy module) to filter and rename 
attributes.  But I don't plan to add the interfaces for that without 
someone's stated intent to use them (such as FreeIPA's).

Down in the weeds, currently the KDC's get_auth_indicators() tries to 
verify the CAMMAC server and KDC checksums and ignores the CAMMAC if 
that fails.  We would need that function to recognize incoming 
cross-realm TGTs and verify only the server checksum (similar to 
get_verified_pac()) but filter the results.