The destructive re-keying problem

[Simo Sorce]

On Fri, 2014-03-07 at 15:37 -0600, Nico Williams wrote:
> On Fri, Mar 7, 2014 at 2:45 PM, Greg Hudson <ghudson at mit.edu> wrote:
> > We've been asked to take a look into automatically invalidating cached
> > service tickets after a server is destructively re-keyed (e.g. if the
> > server is completely re-provisioned and does not retain its old keytab).
> > I did an initial writeup here:
> 
> Clients will still see failures.  They'll just be able to recover if
> the application retries.
> 
> We should try to do a bit better.  There are two ways in which we can
> improve things: on the client side, and on the server side:
> 
>  - On the client side, multi-round trip mechanism enhancements would
> allow the mechanism to recover with no evident failures.
> 
>  - On the server side the KDC could allow old keys to be extracted
> under certain circumstances, namely a) when the host principal was
> marked for this purpose, b) suitable bootstrap credentials are used,
> c) new keys are set, d) only old keys for which unexpired tickets
> might still be floating around are extracted.
> 
> I'd be in favor of both.

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.

For example the multi-round trip mechanism will simply fail in many
situations as the amount of misbehaving applications that simply assume
accept_sec_context will never return GSS_C_CONTINUE_NEEDED is higher
than you may think. And in some cases it is somewhat difficult to 'fix'
them. So client applications still need to be able to recover on their
own.
Just as an example cyrus-sasl gssapi modules misbehave quite easily with
anything not strictly single round-trip :-/

I think yours are reasonable additional steps, but we need the very
basic (yet already hard to achieve) proposal put forth by Greg first.

Simo.

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