Question related to keytab entries upgrade
matthieu.hautreux at gmail.com
Thu Jan 17 05:03:57 EST 2013
Nico, Greg, sorry for the confusion in your identities ! I should have read
again the whole thread before replying.
I tried to take into account Greg explanation (first reply to this thread)
when defining the (1) (2) (3) logic.
Thus having a 'ktutil addent -randkey ...' using krb5_c_make_random_key
sounded to me like a possibility to use kerberos internal RNG on the client
and enforce the equivalent policy that the KDC is using when creating the
new entries. am I correct ?
krb5_admin seems to have a lot of nice feature doing that and a lot more.
If I can just put the logic I described in a local version of MIT packages
that will be sufficient for me. I already had to compile local krb5
pacakages because of unexpected issues with the recently introduced poll
logic (infinite poll loop, I had to disable it) and to add patches for ACLs
on the KDC filtering incoming AS_REQ/TGS_REQ (proposed on this mailing
list in december 2011). I can add that too :).
IMHO the main branch of krb5 would benefit from such a feature to provide
natively an alternate support of hot-add of keytab entries, thus limiting
the race window for indirect hot-add.
If I succeed in doing what I want, I will propose it and see if it seems
interesting enough to be integrated in a future release.
2013/1/17 Nico Williams <nico at cryptonector.com>
> On Wed, Jan 16, 2013 at 5:46 PM, Nico Williams <nico at cryptonector.com>
> > On Wed, Jan 16, 2013 at 5:37 PM, Greg Hudson <ghudson at mit.edu> wrote:
> >> I said it. I wasn't talking about RNG quality. With the setkey RPC,
> >> the KDC doesn't know whether the client chose the key randomly at all;
> >> it could be the string2key output of a password which wouldn't pass the
> >> password policy.
> > Ah, yes, there's that.
> Of course, one can always just deny setkey to principals with password
> quality policies.
More information about the krbdev