[2303] in Kerberos_V5_Development
proposed spec for kadm5_setkey_principal
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Wed Mar 12 14:44:52 1997
Date: Wed, 12 Mar 1997 19:43:25 GMT
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
Ted has requested that I implement a kadm5 function to allow principal
keys to be set explicitly by a caller; currently, a caller can only
set a password (which is expanded to multiple keys based on the realm
enctypes) or can randomize a principal's keys, again creating one per
enctype. This function allows the caller to set the key list
explicitly. The authorization bit required, setkey, is new and not
used anywhere else in the kadm5 system.
Comments, please. This is draft 1.
Barry
--- snip snip ---
\subsection{kadm5_setkey_principal}
\begin{verbatim}
kadm5_ret_t
kadm5_setkey_principal(void *server_handle, krb5_principal princ,
krb5_keyblock **new_keys, int *n_keys)
\end{verbatim}
AUTHORIZATION REQUIRED: setkey. This function does not allow the use
of regular changepw authorization because it bypasses the password
policy mechanism.
This function only exists in KADM5_API_VERSION_2.
Explicitly sets the specified principal's keys to the n_keys keys in
the new_keys array. The keys in new_keys should not be encrypted in
the Kerberos master key; this function will perform that operation
itself (the keys will be protected during transmission from the
calling client to the kadmind server by the AUTH_GSSAPI RPC layer).
This function completely bypasses the principal's password policy, if
set.
\begin{enumerate}
\item If the principal does not exist, return KADM5_UNK_PRINC.
\item If the principal you are trying to change is kadmin/history return
KADM5_PROTECT_PRINCIPAL.
\item Store old key in history.
\item Update principal to have new key.
\item Increment principal's key version number by one.
\item If the POLICY bit in aux_attributes is set, set pw_expiration to
now + max_pw_life.
\item If the KRB5_KDC_REQUIRES_PWCHANGE bit is set in the principal's
attributes, clear it.
\item Update last_pwd_change and mod_date to now, update mod_name to
caller.
\end{enumerate}
This function can also be used as part of a sequence to create a new
principal with an explicitly key. The steps to perform the operation
securely are
\begin{enumerate}
\item Create the principal with kadm5_create_principal with a
random password string and with the KRB5_KDB_DISALLOW_ALL_TIX bit set
in the attributes field.
\item Set the principal's key with kadm5_setkey_principal.
\item Call kadm5_modify_principal to reset the
KRB5_KDB_DISALLOW_ALL_TIX bit in the attributes field.
\end{enumerate}
The three steps are necessary to ensure secure creation. Since an
attacker might be able to guess the initial password assigned by the
client program, the principal must be disabled until the key can be
truly randomized.
