[20424] in Kerberos_V5_Development
Re: Using authentication indicators
daemon@ATHENA.MIT.EDU (Ken Hornstein via krbdev)
Fri Mar 31 21:09:03 2023
Message-ID: <202304010107.33117Nih029913@hedwig.cmf.nrl.navy.mil>
To: Greg Hudson <ghudson@mit.edu>
cc: krbdev@mit.edu
In-Reply-To: <6504e7ac-bef1-8817-4fa4-231baaa51e38@mit.edu>
MIME-Version: 1.0
Date: Fri, 31 Mar 2023 21:07:22 -0400
From: Ken Hornstein via krbdev <krbdev@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>> 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
>of indicators.
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
at least.
>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.
--Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
