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

[Sam Hartman]

>>>>> "Jeff" == Jeff Blaine <jblaine at kickflop.net> writes:


    Jeff> I've found the logic in kdc/kdc_preauth.c where the ordering
    Jeff> of pa stuff is done (around line 896).

    Jeff> How about a PA_REQUIRED flag and its appropriate handler code?

    Jeff> Would that be a welcomed contribution?

 I don't think preauth plugins are the right
place for stuff that is not in the padata field of the packet.  

I think having a mechanism for requiring that a particular set of users
use a particular preauth mechanism would be fine: in particular, if the
expected pa type was not found in the packet, then the KDC should reject
the request with PREAUTH_REQUIRED listing the acceptable pa types for
that user.

I don't think that a mechanism to call a verify routine independent of I
don't think it is a good idea to call a preauth plugin on the KDC side
if the client has not included padata of that type.  That sounds like
an abuse of that facility.

I think that configuration of which pa types should be required for a
given user don't belong in a PA_REQUIRED flag.

I think if you're looking for a facility to decide whether a particular
request should be honored that always runs against the request, then you
would need a new facility.  I think designing such a facility will be a
bit tricky.  Using that type of facility for environment-specific
restrictions seems fine.  For example: in our environment, we never want
to let certain users log in outside of working hours.

However, using such a facility to limit access to specific services
seems highly problematic from a secure interoperability standpoint.  RFC
4120 requires services to handle authorization.  If some KDCs in some
environment will handle some of the authorization, but other KDCs in
other environments do not, then it seems very easy to get a class of
services that are not interoperable with a general purpose KDC or that
are not secure when used with such a KDC.  I'm strongly against that.