Proper way to do logging (KDC) from preauth plugin?

[Greg Hudson]

On Fri, 2010-04-23 at 12:19 -0400, Jeff Blaine wrote:
> I've found the logic in kdc/kdc_preauth.c where the ordering
> of pa stuff is done (around line 896).

This code orders the preauth_systems array, which determines the order
for get_edata and return_padata, but check_padata still uses the order
of padata elements in the request.

> How about a PA_REQUIRED flag and its appropriate handler code?
> 
> Would that be a welcomed contribution?

There is actually already a PA_REQUIRED flag; see line 1168.  The
semantics aren't necessarily intuitive, though.  If a client supplies
padata for a PA_REQUIRED preauth mechanism and the verify_padata method
on that mechanism fails, the request will fail--but if the client does
not supply padata for that mechanism, the request could still succeed.

If my answers seem overly limited, it's because I didn't design this
framework and don't always know the intent of the code.  The big
weaknesses I see are:

  * The KDC configuration is limited to the "preauth required" and
"hardware preauth reuqired" principal flags.  There is no way to
influence the suggested order of mechanisms, to require a specific
preauth mechanism, or to require FAST.

  * There is no way to disable encrypted timestamp in the KDC or client
since it is not a plugin.

  * On the client, there is a hardcoded default of using pkinit in
preference to other mechanisms.  This suggests a poorly-satisfied need
for some kind of prioritization of mechanisms, although perhaps that
need would not exist if KDC configuration could determine the order of
the preauth hint list.

  * The semantics of PA_REQUIRED may be useless.

For your specific use case, the inability to create "inputless" preauth
mechanisms and the inability to get the request's source IP address are
also blockers.