| From: | Sam Hartman <hartmans@MIT.EDU> |
| To: | krb5-bugs@MIT.EDU |
| Subject: | KDC prefers built-in preauth to plugins |
| Date: | Thu, 19 Mar 2009 17:41:32 -0400 |
By default, the client respects KDC preauth order within certain
bounds. However the client will only use one "real" preauth
mechanism. However the KDC prefers built in pre-authentication
mechanisms to plugin mechanisms . This basically means that without
heroic efforts, you end up stuck with encrypted timestamp no matter
what.
There is some logic to prefer mechanisms like pkinit that replace keys
to all other mechanisms. I think something like this is needed,
although I'm dubious about the specific decision. It seems like you
might want to prefer mechanisms that require per-user/per-realm
configuration to mechanisms that do not. Basically if the mechanism's
get_edata_proc might sometimes return "not me", then allow it to do
so.
bounds. However the client will only use one "real" preauth
mechanism. However the KDC prefers built in pre-authentication
mechanisms to plugin mechanisms . This basically means that without
heroic efforts, you end up stuck with encrypted timestamp no matter
what.
There is some logic to prefer mechanisms like pkinit that replace keys
to all other mechanisms. I think something like this is needed,
although I'm dubious about the specific decision. It seems like you
might want to prefer mechanisms that require per-user/per-realm
configuration to mechanisms that do not. Basically if the mechanism's
get_edata_proc might sometimes return "not me", then allow it to do
so.