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

[Jeffrey Altman via RT]

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.

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

> I'm also not sure I buy the idea that kvno should use this interface
> rather than mk_req rd_req.  I don't object to kvno using this
> interface, I'm just not sure it matters.

If we have this interface available, why do the extra work of a
mk_req/rd_req?  what would be gained?

Jeffrey Altman