keytab, kvno, ktadd, and existing tickets

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

keytab, kvno, ktadd, and existing tickets

Chris Hecker

Every time I ktadd to put a key in a keytab for a service, it increments
the kvno.  I assume this is to provide some protection for compromised
keytabs.  However, the existing keytabs to that service are now invalid
(or, at least, fail the kvno check in the sample app if the client gets
a new tkt).  I discovered this because I needed a second copy of a
keytab for testing, and instead of copying the file, I just used kadmin
to generate a new one.  It doesn't look like there's a kvno option to
ktadd to specify it or have it not increment.

I guess I'm asking is the right thing here to just "don't do that"?  I
should just make sure I have a copy of the keytab around at all times
and copy it with cp instead of ktadd'ing to generate a new one?

Slightly related, krb5_cc_remove_cred doesn't seem to be implemented for
file or memory caches, which makes kdeltkt not very useful.  Is this
planned?  Not a big deal, just wondering.

Thanks,
Chris


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

Re: keytab, kvno, ktadd, and existing tickets

Nico Williams
ktadd does not "extract" keys.  It sets new ones.  The fact that the
kvno changes is a side issue -- what breaks you is that the keys
change and you didn't expect that.  MIT krb5 has no other tool to
extract keys without changing them.  However, you can use the -keepold
option to make this a little more tolerable.  The MIT kadm5 API does
allow you to extract keys, but only on the KDC proper (i.e, only when
using libkadm5srv).

If you really need this you might try
http://oskt.secure-endpoints.com/krb5_admin.html
(http://oskt.secure-endpoints.com/git/krb5_admin).  krb5_admin allows
you to extract keytabs and works with MIT krb5.  If you don't go with
this approach then I recommend what you suggested: ktadd on one server
and copy the keytab to the others (if need be using ktutil to merge
keytabs).

Incidentally, Heimdal's kadmin client also can extract keys without
setting new ones, but only with Heimdal kadmind.

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

Re: keytab, kvno, ktadd, and existing tickets

Chris Hecker

> what breaks you is that the keys change and you didn't expect that.

Ah, I think I'm confused by what a "key" is.  I thought it was just the
password for the principal.  What changes about it?

Oh, wait, from reading this, it looks like ktadd actually changes the
password itself, it doesn't just dump it into the file...

http://mailman.mit.edu/pipermail/kerberos/2009-August/015203.html

...oh, and look, that's in man kadmin now that I look closer.  Oops.

And yeah, a ktexport command would be nice in kadmin.  Maybe I'll look
at doing that if I have to do this more often.  This was only during
testing, so hopefully it won't be too common of an occurance.

Chris


On 2011/07/23 00:07, Nico Williams wrote:

> ktadd does not "extract" keys.  It sets new ones.  The fact that the
> kvno changes is a side issue -- what breaks you is that the keys
> change and you didn't expect that.  MIT krb5 has no other tool to
> extract keys without changing them.  However, you can use the -keepold
> option to make this a little more tolerable.  The MIT kadm5 API does
> allow you to extract keys, but only on the KDC proper (i.e, only when
> using libkadm5srv).
>
> If you really need this you might try
> http://oskt.secure-endpoints.com/krb5_admin.html
> (http://oskt.secure-endpoints.com/git/krb5_admin).  krb5_admin allows
> you to extract keytabs and works with MIT krb5.  If you don't go with
> this approach then I recommend what you suggested: ktadd on one server
> and copy the keytab to the others (if need be using ktutil to merge
> keytabs).
>
> Incidentally, Heimdal's kadmin client also can extract keys without
> setting new ones, but only with Heimdal kadmind.
>
> Nico
> --
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab, kvno, ktadd, and existing tickets

Russ Allbery
Chris Hecker <[hidden email]> writes:

> And yeah, a ktexport command would be nice in kadmin.  Maybe I'll look
> at doing that if I have to do this more often.  This was only during
> testing, so hopefully it won't be too common of an occurance.

The code is all there already and would be fairly easy to enable over the
network protocol.  It's not there more as a matter of policy than because
of a lack of implementation.

Ideally, you don't really want to allow redownloading a key because you
enable a silent attack on that key if the attacker somehow gains access to
the kadmin protocol.  If downloading a key always changes it, then the
attacker has to make a visible attack that breaks the existing key and
therefore existing services.  Ideally, you only have one keytab for any
given principal because all of your keys are host-based and you never use
the same key in more than one place.

In practice, the world isn't that nice, so it ends up being a usability
versus security tradeoff.  Many large organizations that I've talked to
have ended up having some need to share the same keytab on multiple
systems for one reason or another.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab, kvno, ktadd, and existing tickets

Chris Hecker

> If downloading a key always changes it, then the attacker has to make
> a visible attack that breaks the existing key and therefore existing
> services.

That makes sense.

Maybe I add ktexport only when building as kadmin.local as a compromise.
  It would allow people to use it for debugging problems (like my use
case), and if they wanted to actually generate a new one "in
production", at least then they'd have to also have root on the KDC,
which, if they had root, they'd be able to just rip it out of the db
anyway with the kadm5 lib like Nico was saying.

If I was in there modifying kadmin.local, I'd also fix the message that
says it's "Authenticating as principal root/[hidden email] with
password." which is not actually true, nor does that princ even exist in
my kdc.  :)  It looks like it already checks for kadmin.local in one
spot, so there's some precedent, although this would need an #ifdef
rather than a dynamic check.

Chris


On 2011/07/23 00:42, Russ Allbery wrote:

> Chris Hecker<[hidden email]>  writes:
>
>> And yeah, a ktexport command would be nice in kadmin.  Maybe I'll look
>> at doing that if I have to do this more often.  This was only during
>> testing, so hopefully it won't be too common of an occurance.
>
> The code is all there already and would be fairly easy to enable over the
> network protocol.  It's not there more as a matter of policy than because
> of a lack of implementation.
>
> Ideally, you don't really want to allow redownloading a key because you
> enable a silent attack on that key if the attacker somehow gains access to
> the kadmin protocol.  If downloading a key always changes it, then the
> attacker has to make a visible attack that breaks the existing key and
> therefore existing services.  Ideally, you only have one keytab for any
> given principal because all of your keys are host-based and you never use
> the same key in more than one place.
>
> In practice, the world isn't that nice, so it ends up being a usability
> versus security tradeoff.  Many large organizations that I've talked to
> have ended up having some need to share the same keytab on multiple
> systems for one reason or another.
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab, kvno, ktadd, and existing tickets

Russ Allbery
Chris Hecker <[hidden email]> writes:

> That makes sense.

> Maybe I add ktexport only when building as kadmin.local as a compromise.

That's already there.  :)  It's the -norandkey option to ktadd in
kadmin.local.

> If I was in there modifying kadmin.local, I'd also fix the message that
> says it's "Authenticating as principal root/[hidden email] with
> password." which is not actually true, nor does that princ even exist in
> my kdc.  :)

Yeah, that's always been weird.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab, kvno, ktadd, and existing tickets

Chris Hecker

> That's already there. :) It's the -norandkey option to ktadd in
> kadmin.local.

I just switched to my mailer to say I looked at the 1.9.1 source to make
the mod and found -norandkey and was thinking "somebody is going to have
replied with 'it's already there'".  :)

CentOS is still on 1.6.1 (!), so I don't have it on the server.  I guess
I'll build latest there if I need it.

Thanks for putting up with all my noob questions and mails!

Chris


On 2011/07/23 01:14, Russ Allbery wrote:

> Chris Hecker<[hidden email]>  writes:
>
>> That makes sense.
>
>> Maybe I add ktexport only when building as kadmin.local as a compromise.
>
> That's already there.  :)  It's the -norandkey option to ktadd in
> kadmin.local.
>
>> If I was in there modifying kadmin.local, I'd also fix the message that
>> says it's "Authenticating as principal root/[hidden email] with
>> password." which is not actually true, nor does that princ even exist in
>> my kdc.  :)
>
> Yeah, that's always been weird.
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos