issue with preauth processing
Nicolas.Williams at sun.com
Fri Oct 23 18:24:25 EDT 2009
On Fri, Oct 23, 2009 at 04:48:58PM -0400, Sam Hartman wrote:
> The preauth framework strongly encourages implementations to take
> optimistic pre-auth as a hint. If you try some pre-auth and get a
> PREAUTH_REQUIRED or PREAUTH_FAILED error, then you should take that as
> the KDC requesting you start over. Now, if that second round fails,
> you should probably give up.
> Basically, the question is whether we take that gic option call as an
> optimization or security constraint. Most people who have used it in
> the past have been looking for an optimization.
First, I get that currently this is a not a "list of pre-auths to try"
option, but with FAST in the picture we're likely going to need such a
thing. In any case the KDC can return a list of pre-auth methods to
try, so one way or another we'll have a loop over pre-auth methods to
Second, I think it's fair for an application to want to avoid the "no
pre-auth" and "plain PA-ENC-TIMESTAMP" methods, even if the KDC might
allow it, in which case you'd want the system to try all other pre-auth
I see this as a security constraint, since if a client just tries
PA-ENC-TIMESTAMP there's harm done (if you worry about off-line
dictionary attacks by eavesdroppers). And since a KDC's KRB-ERROR
saying to try PA-ENC-TIMESTAMP could be spoofed... I really see this as
a security constraint.
I understand that changing the semantics of this gic option now is
probably not acceptable, so maybe we should add a new option to indicate
that the app's pre-auth choice(s) is(are) mandatory, not mere optimistic
More information about the krbdev