Question related to keytab entries upgrade
Matthieu Hautreux
matthieu.hautreux at gmail.com
Wed Jan 16 17:30:08 EST 2013
Thanks for the explanation. I think that Nico said that having the KDC
generating the keys enables to ensure that the keys conform to the security
constraints of the KDC, which explains the reason why setkey privilege must
be added to principal willing to do that. So process 1 and 2 are similar
but only process 2 does not require to have that privilege I guess.
This discussion is interesting and after some additional thoughts I am now
thinking of writing patches to provide the ability to automate the setkey
process to do what I need. Here is what I would like to do, let me know if
you think or do not think it is a valid proposal :
- (1) create a new call in ktutil to add entries with a localy generated
random key (a new -randkey option to addent)
- (2) create a new call in ktutil based on (1) to automatically generate
new entries of incremented kvno for a particular principal and each enctype
found (based on (1) logic)
- (3) create a new call in kadmin based on setkey to automatically sync
(push) particular kvno entries of a principal from a keytab to the kdc
(something like "kadmin -q 'ktsync -k mykeytab myprinc at myrealm [kvno]'")
thus the process to rekey a keytab from the client side would look like :
- (a) ktutil upgrade mykeytab myprinc
- (b) placement of the enhanced keytab in the configuration management tool
- (c) synchronization of the configuration of the targeted node ( (b)-(c)
could correspond to anything else)
- (d) kadmin -q 'ktsync -k myenhancedkeytab myprinc at myrealm [kvno]' to make
the KDC notice and use the new keys
the "kinit -k" issue could ne treated in the lib too to ensure correct
behavior of the server while (d) is not performed.
There is a potential issue during (3) if the locally generated kvno are
lower or equal to the highest kvno of the entries stored in the KDC DB.
However, this could be detected during this stage (3) by first acquiring
the KDC entries to check that the stored kvno is the generated one minus 1.
(that means that the keytab entries prior the upgrade stage (1) must match
the KDC entries, but that seems to be a sensible requirement).
I have already done the (1) as it is quite easy. (2) should not be a
problem so I am working on (3) to validate a first prototype.
I will let you know when I have something working properly. If you think
that I should do that differently, let me know.
Regards,
Matthieu
2013/1/16 Roland C. Dowdeswell <elric at imrryr.org>
> On Tue, Jan 15, 2013 at 11:40:25PM +0100, Matthieu Hautreux wrote:
> >
>
> > I do not exactly see how you manage to simulate the active logic with
> > MIT krb5 implementation. Is it possible or is this description only
> > available for heimdal KDC ?
>
> I'm not simulating the active logic. I am just noting that it doesn't
> actually make a difference. I'll explain with a few more words than
> last time. We have two processes:
>
> PROCESS 1:
>
> a. we are in the unmodified state,
>
> b. we are in the unmodified state,
>
> c. client writes new key into keytab, and
>
> d. client tells KDC about the new key via setkey and the
> KDC writes it into the KDB (which then propagates to slaves).
>
> or
>
> PROCESS 2:
>
> a. we are in the unmodified state,
>
> b. client and KDC negotiate new key and KDC writes in into the
> KDC marking it as inactive,
>
> c. client writes the key into the keytab, and
>
> d. client tells the KDC that it has been written into its keytab
> and the KDC marks it as being active (which then propagates
> to slaves).
>
> Now, if we think about it from a functional perspective, i.e. we think
> about the behaviour of the KDC under both of these processes. In 1.a
> and 2.a, it is clear that the KDCs will behave identically.
>
> In 1.b and 2.b, the KDC will respond in the same way to AS-REQs and
> TGS-REQs. Given that you can't read keys from the database via kadmin,
> the kadmin service will also behave identically.
>
> In 1.c and 2.c, the KDC behaviour changes in neither process but the
> client behaviour changes in exactly the same way.
>
> And in 1.d and 2.d, the KDC behaviour does change in both processes
> but the change is again identical.
>
> Given that the behaviour of both the client and server is the same
> under both processes, we can say that even though the processes
> appear to be very different under the covers, they have exactly
> the same effect. Process 2, however, involves twice as many writes
> to the Kerberos database which with many database backends is a
> limiting factor. And so, it might be an idea to use process 1
> instead.
>
> What I do in krb5_admin{,d} is actually a little different than
> process 1 or process 2, though. I have the client and server use
> ECDH to negotiate new keys, the client writes them into the keytab,
> and then the client tells the KDC to write them into the KDB. The
> server, however, does not store intermediate state in the KDB as
> it is useless if the client crashes in the middle of a transaction---so
> I just keep it in memory. No point in keeping state if it isn't
> useful.
>
> And to continue with the idea that state isn't useful, let us
> examine what the intermediate state (the inactive key) in the
> Kerberos DB gives us in process 2 if the client crashes between
> 2.b and 2.c. Well, unless we relax the restriction that clients
> can't read keys from the Kerberos DB (which I would argue is not
> the correct decision), then the key written in 2.b is of no use to
> the client when it tries to change the keys the next time. This
> leaves us with a bit of a question, which is why did we bother to
> write it into the KDB in the first place?
>
> > You could alter the AS to allow the new key to be used in AS-REQs
> > but I haven't seen that change implemented. I may have missed it.
> > There is an issue with the krb5_admin{,d} behaviour which is that
> > when krb5_keytab writes the new key into the keytab there is a
> > window where kinit -k will fail. This is a less serious problem
> > that the service ticket race condition, however. And I think that
> > the appropriate solution to the problem would be to fix
> > get_init_creds*
> > to be able to use older keys in the keytab if later ones fail---I
> > implement this [locally] in krb5_admin, actually, to avoid failing
> > if the host keytab has corrupt or incorrect entries.
> >
> > Thanks for that information, this is clearly an issue that I missed in
> > my thiking about that as I am also doing regular "kinit -k" on the
> > server nodes... bad news ! If I use the current logic, get the new
> > keytab entries from the KDC and then push them to the node, I get the
> > initial race window, If I generate the keytab on the management node,
> I
> > need to synchronize the push to the KDC and the server or I will get
> > this one :(
>
> The kinit -k race is ``less bad'' than the TGS race, though, because
> the client host can organise kinit -k to run at different times
> than key rotation more easily given that it is a single host.
>
> That said, I think that the Kerberos libs should try older kvnos in a
> keytab if the most recent one fails as I mentioned above.
>
> > I saw that there is a unit-test for setkey in the krb5 source code, so
> > I am thinking about just adding that logic in a local version of
> > kadmin. It would however require to generate properly key material on
> > the client side...
> > Well, I think I need to think about that a little bit more before
> > choosing the proper way for the targeted need. I could just move to
> > cold-add instead of hot-add of entries.
> > Thanks again. I may contact you again in a near future.
> > Regards,
> > Matthieu
> >
> > --
> > Roland Dowdeswell [2]
> http://Imrryr.ORG/~elric/
> >
> > References
> >
> > 1. mailto:elric at imrryr.org
> > 2. http://Imrryr.ORG/%7Eelric/
>
>
> --
> Roland Dowdeswell http://Imrryr.ORG/~elric/
>
More information about the krbdev
mailing list