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

[greg@enjellic.com]

On Apr 23,  1:09pm, Greg Hudson wrote:
} Subject: Re: Proper way to do logging (KDC) from preauth plugin?

Hi, hope the week is starting out well for everyone.

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

All of these issues are more than a bit maddening for anyone trying to
use this infra-structure.

I stomped through these issues doing development work on OTI based
pre-authentication.  The following snippet to a krb5.conf file
makes development efforts a bit more practical:

[libdefaults]
	preferred_preauth_types = "NN"

Where N gets replaced with whatever numeric identifier used to
enumerate your pre-authentication.

Its a bit of a hammer and possibly not useful for production
environments but it does prevent madness with respect to getting a
deterministic development environment.

+1 vote for an MIT 'flag day' 2.0 release which investigates breaking
source compatability to address this and a myriad of other issues
sentencing the distribution to obscurity.

Best wishes for a productive week to everyone.

Greg

}-- End of excerpt from Greg Hudson

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"Don't worry about people stealing your ideas.  If your ideas are any
 good, you'll have to ram them down people's throats."
                                -- Howard Aiken