Using authentication indicators

[Alexander Bokovoy]

On pe, 31 maalis 2023, Greg Hudson wrote:
>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).

We already have a way to modify authentication indicators issued by KDC
through the issue_pac() callback. I consider this enough for FreeIPA
purposes. Our plugins handle other cases already and on cross-realm
operations issue_pac() is already used to filter out SIDs from
PAC-enabled realms like AD or FreeIPA.

My original goal (not implemented yet) for this was to be able to inject
PKINIT-specific authentication indicators to tickets received over
cross-realm when PAC in the incoming cross-tgt contains indication that
PKINIT was used by domain controller in a trusted AD domain. This would
allow us to bridge smartcard use by AD and a lack of authentication
indicators support by Microsoft -- FreeIPA clients would be able to see
the proper indicator for stronger auth support in pam_sss_gss, for
example.

>
>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.
>_______________________________________________
>krbdev mailing list             krbdev at mit.edu
>https://mailman.mit.edu/mailman/listinfo/krbdev
>



-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland