Skip to content
/ krb-rekey Public

automatic rekeying of kerberos service princpals

Notifications You must be signed in to change notification settings

cg2v/krb-rekey

Folders and files

NameName
Last commit message
Last commit date

Latest commit

99bd731 · May 4, 2024
May 4, 2024
Feb 2, 2016
Jan 8, 2021
Nov 24, 2014
Jan 8, 2021
May 25, 2022
Dec 3, 2019
Mar 15, 2013
Dec 17, 2015
Jul 29, 2009
May 25, 2022
May 25, 2022
Dec 7, 2019
Mar 1, 2013
May 25, 2022
Jun 26, 2015
May 25, 2022
May 25, 2022
Dec 3, 2019
Feb 2, 2009
Feb 2, 2009
Feb 2, 2009
Feb 2, 2009
Feb 2, 2009
Feb 2, 2009
May 25, 2022
May 25, 2022
Jun 7, 2010
Nov 24, 2014
Mar 1, 2013
Mar 25, 2009
Feb 2, 2009
May 25, 2022
May 25, 2022
Dec 9, 2019
May 25, 2022
Feb 2, 2009
Mar 7, 2022
Aug 15, 2013
May 25, 2022
Mar 1, 2013
May 25, 2022
Dec 3, 2019
May 25, 2022
May 25, 2022
Feb 2, 2009
May 25, 2022
Jun 29, 2023
May 25, 2022
May 25, 2022
Mar 1, 2013
Mar 1, 2013
May 25, 2022

Repository files navigation

Key management for kerberos service principals

This software allows for automatic rekeying of kerberos service princpals1, even if they are shared. It also includes functionality for initial keying (or key resets) of non-shared principals with random keys.

The software attempts to achieve perfect forward secrecy by encrypting with TLS (DH or ECDH. RSA ciphersuites and server certificates are not used), and then authenticating the connection using GSSAPI and channel bindings. The channel bindings do not formally conform to RFC5056, RFC5554, or RFC5929, but are intended to be equivalent to tls-unique, with each side sending a MIC of the finished messages obtained from openssl2.

There is not any operational documentation beyond the manpage. Please contact cg2v@andrew.cmu.edu or open an issue if you want help setting this up at your site.

The LDAP authorzation mechanisms are tailored to specific Carnegie Mellon LDAP systems and would require adaptation to use elsewhere. There is a simple file based authorization mechanism that is more general

1: Principals which are used only as servers, and never as clients

2: Session resumption is disabled, and RSA ciphersuites were never supported, so this protocol should not be vulnerable to triple handshake attacks.