Proper way to do logging (KDC) from preauth plugin?
greg at enjellic.com
Mon Apr 26 14:21:10 EDT 2010
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:
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.
}-- End of excerpt from Greg Hudson
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
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
More information about the krbdev