issue with preauth processing

[Nicolas Williams]

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

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

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

Nico
--