Using authentication indicators

[Ken Hornstein]

>>    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