Using authentication indicators
abokovoy at redhat.com
Mon Apr 3 05:43:41 EDT 2023
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
>> 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
>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
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
More information about the krbdev