[krbdev.mit.edu #5349] Proposed implementation of krb5_server_decrypt_ticket_keyblock and krb5_server_decrypt_ticket_keytab

[Sam Hartman via RT]

>>>>> "Jeffrey" == Jeffrey Altman via RT <rt-comment at krbdev.mit.edu> writes:

    Jeffrey> Sam Hartman via RT wrote:
    >> In general this seems good.
    >> 
    >> Why do we want the keyblock version of the function?  That
    >> seems like it will encourage a lot of undesirable coding
    >> practices where keys are not stored in keytabs or where
    >> applications do not support keyrollover correctly.
    >> 
    >> We've talked in the past about having a memory keytab to deal
    >> with situations where applications don't have a keytab.  I
    >> think that would be better in this instance.  However I can't
    >> see cases where TLS or RXK5 applications will not have a
    >> keytab.

    Jeffrey> In the RXK5 case, the initial deployments of RXK5 may in
    Jeffrey> fact not have a Kerberos 5 keytab file.  The existing DES
    Jeffrey> keys are stored in the AFS keyfile.  The current code
    Jeffrey> generates a Kerberos 5 keyblock from the key.  It could
    Jeffrey> just as easily generate a MEMORY keytab but we would have
    Jeffrey> to produce the MEMORY keytab implementation first.

Feedback we got even from AFS users on krbdev suggests that we do not
want to accept afs-specific code.  I cannot see any reason for the
keyblock implementation that is not based on artifacts of how AFS is
deployed today.

--Sam