Preauth interface gak_fct cleanup
ghudson at MIT.EDU
Wed Oct 12 23:35:20 EDT 2011
I'm considering making one more change to the preauth interface before
the 1.10 branch, to clean up the gak_fct stuff on the client side. My
* Avoid exposing a copy of the gak_fct contract, which is kind of
problematic because it treats as_key as an in-out parameter.
* Reduce the number of parameters to process_fn and tryagain_fn.
* Do a better job of respecting the malloc barrier.
>From looking at existing preauth plugins, I believe that:
* Encrypted timestamp and encrypted challenge just need to get the AS
key using the enctype, salt, and s2kparams received in etype-info2.
* PKINIT doesn't care about the etype-info2 information, but needs the
enctype of the AS-REP (to know what kind of key to compute) and
needs to be able to replace the AS key.
* SAM2 calls gak_fct with an etype from the SAM challenge body rather
than from etype-info2, and also uses the etype-info2 salt for
purposes other than getting the AS key. However, SAM2 is an
internal mechanism and can cheat, so I'm not worried about its
peculiarities too much.
* OTP needs to be able to replace the AS key.
* Future preauth mechanisms should not be using the etype-info2
parameters (other than perhaps enctype) except to compute the AS key
from a long-term password. (This came up in discussion about OTP,
and led to OTP transmitting its own salt and s2kparams for its own
use of string-to-key.)
What I'd like to do is eliminate the gak_fct, gak_data, salt,
s2kparams, and as_key parameters to process_fn and replace them with
* Get a pointer to the client-supplied reply key, possibly invoking the
* prompter to ask for a password if this has not already been done. The
* returned pointer is an alias and should not be freed.
krb5_keyblock *(*get_as_key)(krb5_context context,
/* Replace the reply key to be used to decrypt the AS response. */
krb5_error_code (*set_as_key)(krb5_context context,
Modules would lose the ability to check if the gak_fct output is
already known before invoking it, but I can't think of a real use case
for that. Modules would also lose the ability to use the etype-info
salt or s2k_params for other purposes.
The get_etype callback would become, I think, half-useless. When
processing a preauth-required error, the etype comes from etype-info2
and (I think) should only be used for the gak_fct. When processing an
as-rep, it's the enctype of the encrypted part of the reply, which is
useful for at least pkinit.
More information about the krbdev