Using authentication indicators
kenh at cmf.nrl.navy.mil
Fri Mar 31 21:07:22 EDT 2023
>> 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.
Ah, okay, I see that now! Whew, following all the various layers there
can be a real bear.
>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.
That's fine with me; just as long as there is some kind of API
that gets them out, that's all I need. I guess if we are assuming
"auth-indicators" is stable and those were all I care about, I wouldn't
even need to call a hypothetical krb5_authdata_get_attribute_types(),
now would I?
>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
Oh, that sounds like a reasonable idea to me.
>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).
Right, I think what you describe would be sufficient to our needs
>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.
Alright, if I get some free time I'll check this out and see if
I can code something up for submission.
More information about the krbdev