The destructive re-keying problem

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

The destructive re-keying problem

Greg Hudson
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:

http://k5wiki.kerberos.org/wiki/Projects/Graceful_recovery_after_destructive_service_rekey

Additional ideas are welcome if people have them.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The destructive re-keying problem

Nico Williams
On Fri, Mar 7, 2014 at 2:45 PM, Greg Hudson <[hidden email]> 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.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The destructive re-keying problem

Simo Sorce-3
On Fri, 2014-03-07 at 15:37 -0600, Nico Williams wrote:

> On Fri, Mar 7, 2014 at 2:45 PM, Greg Hudson <[hidden email]> 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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The destructive re-keying problem

Nico Williams
On Fri, Mar 7, 2014 at 4:59 PM, Simo Sorce <[hidden email]> 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.

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.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The destructive re-keying problem

Simo Sorce-3
On Fri, 2014-03-07 at 18:42 -0600, Nico Williams wrote:

> On Fri, Mar 7, 2014 at 4:59 PM, Simo Sorce <[hidden email]> 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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev