The destructive re-keying problem

[Simo Sorce]

On Fri, 2014-03-07 at 18:42 -0600, Nico Williams wrote:
> On Fri, Mar 7, 2014 at 4:59 PM, Simo Sorce <simo at redhat.com> wrote:
> > In general I agree with your comments Nico, in fact I was the person
> > that asked once more MIT to reconsider the problem, and we had a
> > conversation where we mentioned the possibility to use multi-round trip
> > to recover w/o ever returning errors to applications.
> >
> > And on the server side ability to recover keys in certain situation I
> > also agree, in fact I have a set of patches on the FreeIPA list to add
> > just that ability (subject to access control decisions of course).
> >
> > However I would like to avoid combining all these "solutions" together
> > as something to deliver all at once.
> 
> The three options (my two plus Greg's marking bad tix in the ccache
> option) have no dependencies on each other, therefore all can be
> pursued independently.  I didn't say otherwise, and I fail to see how
> I implied otherwise either.

It seemed a request to pursue all at once, apologies if it wasn't meant
that way.

> BTW, since the KRB-ERROR in the wrong kvno case is NOT protected, the
> client is taking a small risk in marking that ticket bad in the
> ccache.  A small security consideration, and not a new one at that.

Yes, this was also considered, the effect of an attacker playing with
errors would be an increased number of TGS requests to the KDC. However
in the discussion with Greg I proposed we actually mark a successful
request and try to re-acquire tickets only if a previously successful
request was ever made. So should an attacker cause two consecutive
failures the client would stop retrying to ask the KDC until a
successful authentication with the ticket in the cache.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York