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

Greg Hudson ghudson at MIT.EDU
Fri Apr 23 13:09:45 EDT 2010

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.

More information about the krbdev mailing list